Changing the Permissions of Participants
The set of
permissions is listed in the
Permissions column of the table. By default, a subset of permissions are displayed and, depending on the context you are in, you may not be able to change any of the permissions. The
security preferences determine which permissions are displayed in the
Permissions column and whether the user interface allows you to change what is displayed.
After each permission, the following options are available in a drop-down list:
• No Change � Indicates that you do not want to change whether the permission is granted.
• Add � Indicates that you want to add an ad hoc access control rule setting that grants the permission for the specified participant.
• Remove � Indicates that you want to remove an ad hoc access control rule setting. For most objects, permissions granted with source designations other than Access Control (such as policy access control rules or life cycle or workflow ad hoc access rules) are not removed. For shared objects managed from the context to which they were shared, permissions granted with source designations other than Sharing are not removed. Permissions granted to other participants (such as a group or organization in which the selected participant is a member) are not removed.
For those objects that have an associated life cycle, all changes made to permissions through the Access table apply to the object when it is in all of the life cycle states (not just the current life cycle state of the object).
When the selections you have made in the table reflect how you want the permissions changed for the displayed participants, click OK to make the changes and close the window.
When processing your request to change a set of permissions for multiple objects, Windchill verifies that you are allowed to make the changes. If for any reason, the requested changes cannot be made for all objects, none of the changes are made and an error message is returned.
Windchill also determines which of the multiple objects that you have selected require updates to the ad hoc permission settings that are currently set. Changes to the existing set of permissions are not made if the existing rules that are in effect already cover the intended update. For example, assume that a user has already been granted the Full Control permission on an object and, as part of an access control update to multiple objects, the Read permission is added. In this case, Windchill ignores the addition of the Read permission for this object and the Full Control permission remains. In another example, assume that three objects are selected and the user already has been granted the Download permission for two of the three objects. In this case, adding Download from the Access table actually adds an ad hoc access control rule for only the one object that the user had not been granted the Download permission. The rules for the other two objects do not change.
Because there are multiple ways of setting access control permissions, you may not be able to remove the ability of a user to perform an action (such as modifying a file). For example if the Modify permission has been granted to a specific user because of the life cycle state the object is in, then you cannot remove the Modify permission setting because the ad hoc rule granting Modify rights was set by the life cycle interface.
Another reason that a user could still be granted certain rights even though you have removed the permission setting from the ad hoc rule that grants those rights through the Edit Access Control interface is that the user is a member of one or more groups that are still granted the right. For example, assume the following:
• The ABC project has a user named Chris Jones who is a member of the team in the role of Consultant for this project and is a member of the ACME organization.
• All members of the ACME organization are granted the Read permission for all documents in the ABC project. The Read permission is granted through an access control policy rule.
• All members of the Consultant role in ABC project are granted the Read, Modify, Download, and Modify Content permissions for a couple of documents named Project Requirements and Project Overview using the Edit Access Control interface.
Later you decide that you do not want Consultants to be able to view, modify, or download the Project Requirements and Project Overview documents. To accomplish this, you select the documents and then select the Edit Access Control action from the table Actions list. From the Team Access view, you select Remove for the Read, Modify, Download, and Modify Content permissions in the Consultant row and click OK. After performing this action, members of the Consultant role in ABC project no longer have Read, Modify, Download, and Modify Content permissions for the two documents; however, since Chris Jones is a member of the ACME organization, Chris still has Read permission on the documents.
After using the
Edit Access Control interface to add or remove ad hoc permission settings, you can verify that the permissions for an object are set according to your expectations by
viewing the access details of a single object and participant. If security labels are enabled, then a user could be further restricted by security labels, and thus unable to view objects and perform actions that permission settings would otherwise allow.