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:

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:

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.