Introduction
This document is initially based an Excel-file I got somewhere (I think from Mike). If the original author comes foreward, I will be pleased to grant him the credits.
I didn't check all the statements, I added some of my own. The document is far from complete. May I invite you to do the same, so this document may grow in the community.
At this moment, I'm not sure whether or not the format is the most appropriate. I've some difficulties with the formatting. Maybe we have to revert back to Excel 😞
For your convenience : the general structure is : Object Type > User Action > ACL (> Additional comment on ACL). So, the focus is to document the ACL's needed to allow/disallow certain user actions.
This document is written based on experience in Windchill 9.1.
General Comments
Set State
Set State only appaers when the Set State transitions are configured in the lifecycle. Only those states are selectable that are configured in the lifecycle of the object. Unless the user is either an Admin, or has Administrative ACL.
New Object
The ability to create in a Folder does not require Modify or Modify Content permission for the SubFolder object. Modify for the SubFolder relates only to Renaming it; Modify Content for the SubFolder seems to be n/a.
Rename Object
This is a serious user action if there are multiple Revisions in an object's history. Once renamed, users can no longer search for the object as it was at the time when used for business purposes. There is only the Rename history.
Tabel with details
| Object Type / User Action | ACL | Comment |
|---|
Cabinet | | |
| (Access) | Read | Required in order to see all elements in Folders subtab UI of a context and to do any work in the context. |
| Modify | No direct user action / menu pick results from providing Modify for Cabinet, but it is prerequisite for all create actions (including Revise) in the related context. |
SubFolder | | |
| (Access) | Read | |
| New Folder | Create | |
| Edit Folder | Read | |
| Modify | Modify by itself is required for moving an object (e.g document or Part) to the Folder. Modify by itself results in nothing related to renaming, but it must be added in combination with Modify Identity in order for the user to be able to Rename. |
| Modify Identity | Both Modify and Modify Identity required to rename a folder. |
WTDocument | | |
| (Access) | Read | |
| Download Primary File | Read | |
| Download | The menu pick says "Primary File" but in fact one ACL provides the ability to download both the primary file and any attachment files. |
| New Document | Create | Read not needed to create (but makes no sense not to have Read). Create needs to be at ALL states, or at first state of Lifecycle assigned to Document by OIR. Best practice is at first state. |
| Delete | Create | |
| Delete |
|
| Delete Non-Latest Iterations | Create | |
| Delete | Displays only where there is more than 1 iteration at the current revision. Applies to all states that the existing non-latest Iterarations for the current revision are currently at. |
| Edit / Check Out (and Edit) / Check In | Read | |
| Modify | Allows the user to Check Out. From there, the user can either Edit or Undo CheckOut. |
| Check Out and Download | Read | |
| Download | |
| Modify | Without Modify Content, user can only edit metadata, not the primary or attachement files. |
| Modify Content | With the addition of Modify Content, the user can replace the files. |
| Replace Content | Read | |
| Modify | Without Modify Content, user can only edit metadata, not the primary or attachment files. |
| Modify Content | With the addition of Modify Content, the user can replace the files. But it requires Modify. |
| Rename | Read | |
| Modify Identity | Allows a user to edit the Number and/or Name. The permission has to be either to ALL states or each state in the object's history. |
| New Revision | Read | |
| Revise | For all users, new Revision only appears when at a lifecycle state from which the Revise transition has been configured. Also required: Create at state which results from Revise transition from current state, conifigured in lifecycle. Also required: Modify for the Cabinet for this context. Note: The preference "Allow Override On Revise" allows user to specify a Revision other than the next in the series if set to yes (default is no). |
| Set State | Read | |
| Set State | |
| Move | Read | |
| Create By Move | This one governs where the object ends up (create here). The permission has to be either to ALL states or each state in the object's history. |
| Change Domain | Multiple permissions required for moving. This one governs where the object ends up (create here). The permission has to be either to ALL states or each state in the object's history. |
| Change Context | Multiple permissions required for moving. This one governs where the object ends up (create here). The permission has to be either to ALL states or each state in the object's history. |
| Add to Project | Read | |
| Download | Required in addition to Change Permissions |
| Change Permissions | One would never guess this, but this is the ACL to enable this menu pick. |
| ReAssign Lifecycles | Read | Required in addition to Change Permissions |
| Administrative | |
| | |
EPMDocument |
| |
| To be completed | to be completed | |
WTPart | | |
| (Access) | Read | |
| New Part | Create | |
| Delete | | |
| Delete Non-Latest Iterations | | |
| Check Out (and Edit) / Edit / Check In | | |
| Edit Bill of Materials | | |
Edit Common Attributes | | |
| ReAssign View | | |
| Rename |
| |
| New Revision | | |
| Set State | | |
| Move | | |
| Add to Project | | |
| ReAssign Lifecycles | | |
| New View Version | | |
| New One Off Version | | |
| New Part Configuration | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
Final Remarks
Lifecycle configuration
Although the policy administrator is the better option for access rights configuration, lifecycles are sometimes an option as well.
E.g.: Delete for the creator of a WTdocument is easily ackomplished through lifecycle config.
