When importing an eQ to a GSM spec, the global transient workflow is automatically selected as the workflow to use. However, in this workflow, the spec owner does not have read permissions on the specification. This doesn't really make sense, as it means the person who does the actual importing can not read the specification. This issue has been documented first in a bug report: "Bug 14193733 : EQ TO GSM ASSIGNS TRANSIENT WORKFLOW TO NEWLY CREATED GSM SPEC" and this was closed as not a bug. It was then turned into an enhancement request in "Bug 14692354 : ABLE TO ASSIGN WORKFLOW TEMPLATE IN THE EQ>>GSM INSTEAD OF DEFAULT TO TRANSIENT". While this admittedly might not be a bug, it seems like a highly undesirable feature. Is there any sort of workaround for this issue?
Is there anyone else out in the PLM4P user community having this issue?
1. Are your users able to import from eQ to GSM and have access to the new issue or update specs they create?
2. Are your imported Specs assigned to the Transient Workflow or does the spec find the proper workflow?
3. If answering "Assigned to Transient" for Question #2, how is your configuration or business process working around this?
Thanks for any input. --Beckie
When pushing from eQ to GSM, the spec is assigned to the transient workflow. This is as designed. However, per the transient workflow template, the eQ user who creates the spec should have read/write access to the spec, and it should show up in their action items. It is that user's responsibility to open the spec and resolve it to the appropriate workflow template. If this is not working, and the eQ user who creates the spec cannot open the spec, then I suggest submitting an SR.
Thank you for the clarification. I did submit an SR a while ago and it is still open. I'm trying to figure out how to solve the issue for our users and thought the forum users would know how to work around it. It is a major pain point for our Supplier Collaboration and user adoption efforts that I want to get solved.
a thought came up. if you look at your transient workflow in WFA, you should see the following permissions:
Read Global Status =
Write Author Status = Draft
Write Owner Status =
Global is a root level user group, and I believe most customers are trained to add groups under global. however, if you have users in groups outside of global, then it's possible you would experience the behavior you mentioned.
can you check your groups to see if you have users in groups that are not part of global?
Matt, thank you for your reply.
Two alarm bells are going off in my mind from this post.
First, is none of our user groups are under the Global group root group. Nearly all of our groups are at the parent level. Is the recommended Group administration to create user groups under the Global parent?
Our 18.104.22.168 Upgrade has only the following in Transient Workflow ...
Read Global Status =
Write Author Status = Draft
There is no line item for Write Owner Status =
And I do not have the ability to edit a system WF in the portal WFA.
I can try setting our R&D user group to have the Global parent to see if that changes the applications behavior without breaking our security model. I cannot add the Owner permissions to the Transient workflow. I also fail to understand why GSM would not allow Author to have Read ability on Transient since that should be implicit with the Write permission.
1. "none of our user groups are under the Global group". For a group to properly use the transient workflow, it must be part of the Global group. were you able to test moving the R&D user group under Global?
2. "There is no line item for Write Owner Status =". Your DB is correct. I am looking at a database I would consider "dirty". I did not pull it from the certified DB.
3. "I do not have the ability to edit a system WF". Correct, as a system WF, we do not want users editing the transient workflow.
4. "why GSM would not allow author to have read ability on transient...". For workflows, we treat read and write as separate permissions. under all other circumstances, this is not a problem. we do not want to make changes to the transient workflow, however, we could probably safely add "Read Author Status = " without impact. let me follow up internally and get back to you.
in the meantime, please let me know if moving R&D under global resolved the issue.
1. Yes, I did place our R&D group under \Global\GSM\ and the application behavior changed to the desired results on Transient workflow. At this time, I am testing to determine if this breaks our security model because we don't understand why we would have inheritted the user group setup as it is today unless there is some other issue that we need to avoid by using the parent Global. I have that out as a question to Steve Dezell.
2-4. When I saw your answer, I was convinced that my DB was broken from install. I have even consider 'Brute Forcing' insert statements into the DB to get the application behavior needed. I want to allow our users to do their jobs without feeling like they are doing something wrong and getting undeserved error messages. I also find it good to know that Implicit Read is not inclusive of Write on Workflows. That's not intuitive and I would not have thought that of the Transient workflow expect for this experience. I have spent a lot of time and emotion on trying to get this fixed because it made no sense to us. I'm glad someone is finally listening.
Edited by: Beckie on Nov 19, 2012 2:32 PM
FYI, Bug 14692354 (Enhancement Request) was updated last week and is said to be resolved using GSM templates in 6.1.0. When creating a specification using eQ, it is necessary to select a template and the template will have the workflow set so the specification will be automatically resolved.
Hope this helps,
Edited by: user743027 on Nov 20, 2012 9:16 AM
OK, I'm still confused. OCS says that Write permission includes Read, but we have proved this is not true on workflows. We do not have templates yet we still wish to use the eQ>>GSM functionality.
What is the resistance when we ask that explicit read for author at Draft be added to Transient? This would solve our issues without having to go through hoops to work-around to use the import functionality.
Is there something that we are just not seeing because I truly don't understand why this is not the answer to the problem we have presented.