cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Visit the PTCooler (the community lounge) to get to know your fellow community members and check out some of Dale's Friday Humor posts! X

Correct ACL to Revise an Object but not Allow Modification

BrianToussaint
19-Tanzanite

Correct ACL to Revise an Object but not Allow Modification

I am using Windchill PDMLink Release 11.1 and Datecode with CPS M020-CPS08

I am trying to Revise an object at a state where I do not want to allow modify or modify content. What are the ACLs that I need to have for this? On both the current state and the state that it needs to be at? I found an article that says that I need to have Create at the "to be" state but that didn't seem to work.

Here are the errors that I faced
none
1 ACCEPTED SOLUTION

Accepted Solutions

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).

View solution in original post

9 REPLIES 9

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).

TomU
23-Emerald IV
(To:BrianToussaint)

See if this helps:

 

TomU_0-1645046232712.png

TomU_1-1645046330478.png

 

BrianToussaint
19-Tanzanite
(To:TomU)

@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.

 

2022-02-17_7-17-34.jpg2022-02-17_7-13-06.jpg

TomU
23-Emerald IV
(To:BrianToussaint)

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?

BrianToussaint
19-Tanzanite
(To:TomU)

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. 

HelesicPetr_0-1645169846188.png

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.

@cgautier I have verified that I have that set and it still is not working. 

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.

mlockwood_0-1645115066235.png

 

mlockwood_1-1645115083059.png

 

Top Tags