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

Detailed explanations of Access Control Rule Permissions ?

SOLVED
Participant

Detailed explanations of Access Control Rule Permissions ?

How can I find detailed explanations of Access Control Rule Permissions ? (Administrative,Modify,Modify Content,Modify Identity etc.)

1 ACCEPTED SOLUTION

Accepted Solutions

Re: Detailed explanations of Access Control Rule Permissions ?

Can,

While these are not the "official" definitions from PTC, here's my understanding of the permissions, using a WTDocument as the item it is applied to as an example:

Full Control: combination of all the permissions below.

Read:  see the object in Windchill

Download: if the object has content (primary or attachments), download a copy of the content to your computer 

Modify: check out, edit attributes, and check in the object

Modify Content: upload additional, remove, or change the uploaded content

Modify Identity:  change attributes associated to the master object (for WTDocument this would be name and number - this essentially allows the "Rename" command)

Create By Move: create a copy of the object using the "Save As" function

Create: make a brand new instance of the object

Set State:  use the "Set State" action to set the life cycle state directly on the object (different from a promotion or change)

Revise:  Update the revision to the next value in the series (or to any future value, depending on preferences)

New View Version:  not commonly used in my experience, but you can create a new view of this object.  I believe this applies more to WTParts having either a design view or a manufacturing view

Change Domain:  again not commonly used in my experience, but this allows you to change the set of policies that govern the object (such as ACLs) without changing other attributes on the object.

Change Context:  move the object to a different product/library

Change Permissions:  allow the ad-hoc granting of abilities particular to this object (note that you cannot "ad-hoc deny", or overwrite an ACL deny)

Delete: completely remove the object from WC

Administrative: also not commonly used in my experience, I believe this allows the user to perform actions on the object that typically only Org/Site administrators can do ... possibly such as "Reassign Life Cycle" may be one of them.

Implementing ACLs can get a bit complex, so if you're looking for some advice/help on implementing ACLs in your system I'd be happy to help you out!

4 REPLIES 4

Re: Detailed explanations of Access Control Rule Permissions ?

Can,

I think your request is more for Windchill admin that for CAD Integration section.

Ryan Kelley‌ can move it for you.

Marco

Re: Detailed explanations of Access Control Rule Permissions ?

Can,

While these are not the "official" definitions from PTC, here's my understanding of the permissions, using a WTDocument as the item it is applied to as an example:

Full Control: combination of all the permissions below.

Read:  see the object in Windchill

Download: if the object has content (primary or attachments), download a copy of the content to your computer 

Modify: check out, edit attributes, and check in the object

Modify Content: upload additional, remove, or change the uploaded content

Modify Identity:  change attributes associated to the master object (for WTDocument this would be name and number - this essentially allows the "Rename" command)

Create By Move: create a copy of the object using the "Save As" function

Create: make a brand new instance of the object

Set State:  use the "Set State" action to set the life cycle state directly on the object (different from a promotion or change)

Revise:  Update the revision to the next value in the series (or to any future value, depending on preferences)

New View Version:  not commonly used in my experience, but you can create a new view of this object.  I believe this applies more to WTParts having either a design view or a manufacturing view

Change Domain:  again not commonly used in my experience, but this allows you to change the set of policies that govern the object (such as ACLs) without changing other attributes on the object.

Change Context:  move the object to a different product/library

Change Permissions:  allow the ad-hoc granting of abilities particular to this object (note that you cannot "ad-hoc deny", or overwrite an ACL deny)

Delete: completely remove the object from WC

Administrative: also not commonly used in my experience, I believe this allows the user to perform actions on the object that typically only Org/Site administrators can do ... possibly such as "Reassign Life Cycle" may be one of them.

Implementing ACLs can get a bit complex, so if you're looking for some advice/help on implementing ACLs in your system I'd be happy to help you out!

Re: Detailed explanations of Access Control Rule Permissions ?

Modify: + Rename, Edit Common Attributes

Modify Identity: Only Renumber

Re: Detailed explanations of Access Control Rule Permissions ?

Have to be very disciplined planning for and implementing ACLs - and need to do so in close coordination with a few other configurations including groups, lifecycle states and whether each Product/Library context is "private" or not.

The effect of each also depends on the object type.

Example

Modify permission for an object that can be checked out (e.g Documents and Parts) results in the Check Out action being available.  The user action results in an Iteration.

Modify permission for an object that can nbe edited (e.g. Change Request) results in the Edit action being available.  The user action results in an edited object, but no Iteration.

For Checked Out objects, the Modify Content permission has no effect unless the user also has Modify.  But - For Editable objects, the Modify Content permission is independent of the Modify permission.

For this reason, you pretty much have to work carefully by object type.  It's a good idea to create one each of every object type at every state and permenantly leave in the system - then access each with a test user that represents a group (or however users are given permssions).

Another potential gotcha: ACLs are assigned by state.  If you use the same state in multiple lifecycle templates for different purposes, have to keep all in mind.

Best tool to confirm all is Manage Security, accessed from each object (at a specific state).