Open Rules for Cabinets
Another strategy for applying access control to objects is to define relatively open rules for access to the cabinet (applied to its ancestor type WTObject), and then to add more rules that deny access to certain object types.
For example, you may decide that
Only members of the Bicycle Company organization are allowed to create or delete Specification documents, though individual users outside the organization are also able to perform these actions.
Product team members are allowed to create an delete objects in the In Work state within the product’s Default cabinet and its folders.
All team members are allowed to view and modify object attributes (other than those controlled by the Modify Identity permission) and contents in all states, with some exceptions.
Members of the Supplier role are never allowed to create, delete, or move objects within the product’s Default cabinet and folders.
Members of the Supplier role are never allowed to modify Specification documents.
Members of the Engineers role are never allowed to modify Specification documents in the Released state.
The following rules (defined for the domain to which the shared Default cabinet and its folders belong or for an ancestor of that domain), would support this strategy:
Object Type
State
Permissions
Participant
Specification
All
Granted:
All except Bicycle Company
Denied: Create, Delete
Absolutely Denied:
WTObject
In Work
Granted: Create, Delete
Team Members
Denied:
Absolutely Denied:
WTObject
All
Granted: Read, Download, Modify, Modify Content
Team Members
Denied:
Absolutely Denied:
Cabinet
All
Granted:
Supplier
Denied:
Absolutely Denied: Modify
SubFolder
All
Granted:
Supplier
Denied:
Absolutely Denied: Modify
Specification
All
Granted:
Supplier
Denied:
Absolutely Denied: Modify, Modify Content, Modify Identity
Specification
Released
Granted:
Engineers
Denied:
Absolutely Denied: Modify, Modify Content, Modify Identity
Was this helpful?