Solved! Go to Solution.
1. The LIfecycle template determines from which states Revise is possible, regardless of permissions. Revise can only be to a single state from any start state.
2. Revise permission is given at the starting state. Because Revise essentially "creates" a new Revision, the Create permission at the resulting state is also required. For the OTB Basic lifecycle (simple), users are generally given Modify / Modify Content at In Work, so giving Revise at Released allow Check Out at the resulting In Work state after Revise.
3. For more complex lifecycle templates (e.g. two phase), Revise will generally end at a state which is not the first state and Create is needed at this state. Note: There is no way to directly create a new object at a state that is not the first state.
4. In general, Modify is required after Revise, so it should be planned that appropriate users can Modify at the resulting state. You may want to limit who can Modify by state (e.g. Groups or Roles).
1. The LIfecycle template determines from which states Revise is possible, regardless of permissions. Revise can only be to a single state from any start state.
2. Revise permission is given at the starting state. Because Revise essentially "creates" a new Revision, the Create permission at the resulting state is also required. For the OTB Basic lifecycle (simple), users are generally given Modify / Modify Content at In Work, so giving Revise at Released allow Check Out at the resulting In Work state after Revise.
3. For more complex lifecycle templates (e.g. two phase), Revise will generally end at a state which is not the first state and Create is needed at this state. Note: There is no way to directly create a new object at a state that is not the first state.
4. In general, Modify is required after Revise, so it should be planned that appropriate users can Modify at the resulting state. You may want to limit who can Modify by state (e.g. Groups or Roles).
See if this helps:
@TomU @MikeLockwood Please see below. I seem to have the correct setup. I have the permissions set at the ORG level and have checked my permissions for the different context inside the ORG.
Looks okay. What behavior are the Design Engineers seeing when an object is at the Active state? Is the revise button visible? If it is available, is an error message thrown when attempting to revise? Are objects crossed out in the collector and listed as not eligible for revise?
It was giving me the revise and then the objects were crossed out. Originally I was getting an error in a custom program that it couldn't complete, but there was no log for it or what was causing it. I originally missed one permission value but it still didn't work after that. So I decided to stop Windchill and clear the cache. I also cleared the temp files. I also refreshed the user after it restarted and now it seems to be working. It is one of those things that is frustrating.
hello @BrianToussaint
It happens very often if you use more then one Methodserver.
If you manipulate with ACL rules and users in roles the ACL Cache is not cleaned. An ACL rules are not correct for user even the system shows it correctly.
There is the easiest way how to solve it without restart. in Participants use the Remove from cache action to cleanup ACL cache for that user.
Hope this can help
Best Regards
PetrH
Hello Brian Toussaint
I'm Charles from PTC Technical Support in Europe, I'm contacting you regarding your question: 'Correct ACL to Revise an Object but not Allow Modification'.
Have the information already provided by mlockwood and TomU been helpful somehow?
KR,
Charles.
Also, please remember that the best tool to investigate / verify user permissions is from an object (e.g. a CAD Doc) at in a context of interest, at a state of interest, to select Edit Access Control. Observe the checkmarks for permissions by Role / Group. Also then add specific user(s) and observe the check marks.