Access Permissions
Permissions represent the operations that can be performed on an object. When you create or update access control rules, you establish the permissions a specific participant (user, group, organization, or role) is granted, denied, or absolutely denied for objects within a domain.
The following table lists the access permissions and describes the possible rights that are granted, denied, or absolutely denied:
|
Access Permission Rights
|
|||
|---|---|---|---|
|
Permission
|
Description
|
||
|
Full Control (All)
|
A participant (user, group, organization, or role) granted the Full Control (All) permission is granted all permissions currently defined and any defined in the future. Therefore, if new permission types are defined, you do not have to write rules that specifically grant them to participants with full control access.
|
||
|
Read
|
The right to know the existence of an object and to view the object and its attributes. Additionally, if the object has content, you can view an object's content information such as the file path to a local file or the location of external storage. This permission does not allow you to view the actual contents of the file.
|
||
|
Download
|
The right to download local files that are the primary content or are attachments of an object. This right is applicable to objects with content, such as documents or drawings.
|
||
|
Modify
|
The right to change the attributes of an object, as well as other characteristics that are part of the object definition but are not controlled by the Modify Content, Modify Identity, or Modify Security Labels permissions.
For versioned objects, a participant must have the Modify permission on the latest iteration of each version of a target object to update the attributes common to all versions that are not part of the object’s identity. Modify permission on a version of a target object is required to modify that version’s attributes.
|
||
|
Modify Content
|
The right to modify any local file, URL, or external storage for the primary content and attachments of an object with content. This includes modifying content information and adding, replacing, or deleting content.
|
||
|
Modify Identity
|
The right to modify a subset of the attributes that determine the identity of an object.
For a part, this subset includes the part number and the organization identifier (such as cage code) of the part, but not the part name. The part name is often treated as a short description.
For a folder, the attributes include the folder name.
The subset of attributes affected by the Modify Identity permission for a given object type is determined through the annotation of classes. For information on customizing the code to modify the set of attributes used in determining the identity of an object, see Identified Business Classes in the Windchill Customization Guide.
|
||
|
Modify Security Labels
|
The right to modify security label values on an object.
|
||
|
Create By Move
|
The right to move an object into an administrative domain.
|
||
|
Create
|
The right to create an object.
|
||
|
Set State
|
The right of a participant to perform a set state operation where a state transition has been defined to allow the transition from the current life cycle state to the new state.
|
||
|
Revise
|
The right to revise an object. Revising creates a new version of the object at the same level as the original in the version tree. For example, you can create revision B from revision A.
|
||
|
New View Version
|
The right to create a new view version of an object. The New View Version action creates a new version of the object in a descendant view. The revision identifier sequences between views are independent. For example, you can create A.1 (Manufacturing) from B.1 (Design). For more information about views, see Working with Views and View Associations. For more information about new view versions, see Out-of-the-Box Default Versioning Scheme.
|
||
|
Change Domain
|
The right to move an object out of an administrative domain.
For information about administrative domains, see Managing Access to Data through Access Control Rules.
|
||
|
Change Context
|
The right to move an object out of a context.
|
||
|
Change Permissions
|
The right to change the ad hoc permissions that others have.
Participants who are granted the Change Permissions permission are allowed to change the ad hoc permissions of other participants. They can change these permissions to the permissions they themselves have or to a subset of the permissions they have.
|
||
|
Delete
|
The right to delete an object.
|
||
|
Administrative
|
The right to perform certain administrative tasks. For example, an administrator would have the right to undo another user's checkout or set an object to an arbitrary life cycle state.
|
||
Not all permissions apply to all object types. After you select an object type in the New Access Control Rule window, the permissions that do not apply are disabled. For example, not all object types support versioning. When an object type that does not support versioning is selected, permissions that do not apply to that object type are disabled. This includes the Revise and New View Version permissions.
Some of the operations a user wants to execute require that the user has multiple permissions on one or more objects. To ensure that users can execute the operations, you must become familiar with the required permissions needed to do the operations. The following table lists a couple of common operations and the corresponding permissions required to execute the operations.
|
Operation
|
Required Permissions
|
|---|---|
|
Move an object from one folder to another folder
|
Requires the Modify permission on both the source and destination folders.
If the domain of the object changes as a result of the move, then the operation requires the Change Domain permission on the object being moved (before the domain change) as well as the Create By Move permission (after the domain change).
If the context of the object changes as a result of the move, then the operation also requires the Change Context permission on the object being moved (before the context change).
|
|
Revise an object
|
Requires the Revise permission on the object being revised and the Create permission on the new version.
|
 |
In addition to having the permissions required for an operation, users are required to have Read permission on any object displayed in the user interface while they are performing the operation. For example, to navigate to an object that is contained in a folder, users must have Read permission on the folder as well as the object in the folder.
|
For more information about the permissions required for the user interface actions available to users, see the Access Control reference topics.
Selecting certain permissions in the New Access Control Rule and Edit Access Control Rule windows automatically selects other permissions when permitting access to an object type. For example, if a group is given permission to create an object, the group usually requires permission to read and modify the object as well. To override an automatic selection, click the corresponding None radio button.
The following table identifies which permissions are selected automatically for each permission granted:
|
Permission
|
Selects
|
|---|---|
|
Full Control (All)
|
None
|
|
Read
|
None
|
|
Download
|
Read
|
|
Modify
|
Download, Read
|
|
Modify Content
|
Modify, Download, Read
|
|
Modify Identity
|
None
|
|
Modify Security Labels
|
None
|
|
Create By Move
|
Read
|
|
Create
|
Create By Move, Modify Content, Modify, Download, Read
|
|
Set State
|
None
|
|
Revise
|
Create By Move, Modify Content, Modify, Download, Read
|
|
New View Version
|
Create By Move, Modify Content, Modify, Download, Read
|
|
Change Domain
|
None
|
|
Change Context
|
None
|
|
Change Permissions
|
None
|
|
Delete
|
Modify Content, Modify, Download, Read
|
|
Administrative
|
None
|
Administrators can change what permissions are selected automatically for a granted permission by setting one of the wt.access.permissionImplies.* properties in the wt.properties file.
Related Topics