Restrictive Rules for Cabinets
One way to manage access control for Windchill objects is to define rules granting limited access to the cabinet (applied to its ancestor type WTObject), and then to add more rules that grant some participants additional permissions for specific foldered object types. In general, this strategy uses the potential of shared cabinets for use as an information storage vault.
For example, you may decide that all members of the Bike Company organization should be allowed to search for and view objects in a product’s Default cabinet. In addition, the product’s team members should be allowed to see the shared Default cabinet and its contents when they are navigating in the folder browser within the product. Also assume that only members of the Engineer and Designer roles should be allowed to check out and modify Specification (which is a subtype of WTDocument) documents stored within that cabinet and only when in the In Work and Under Review states. Assume members of the Designer role should also be allowed to create Specification documents in the In Work state within the cabinet and folders. The following rules (defined for the domain to which the shared Default cabinet and its folders belong or for an ancestor of that domain), support this strategy:
Object Type
State
Permissions
Participant
WTObject
In Work
Granted: Read, Download
Bike Company
WTObject
All
Granted: Read, Download
Team Members
Specification
In Work
Granted: Modify, Modify Content
Engineer
Specification
In Work
Granted: Modify, Modify Content, Create
Designer
Specification
Under Review
Granted: Modify, Modify Content
Engineer
Specification
Under Review
Granted: Modify, Modify Content
Designer
SubFolder
All
Granted: Modify
Designer
Cabinet
All
Granted: Modify
Designer
All folder members must reside within a cabinet or a subfolder. In addition to permissions such as those above, the required rules described in Foldered Information apply.
Было ли это полезно?