Denying Access Rights

For a given node at a given level, grant records are examined until one gives a user or group permission to perform an operation or until all the grant records have been examined without finding one that gives permission. If membership in one group does not allow a user to perform an operation but membership in a second group does, the user can perform the operation. However, if a deny record for that node forbids the user from performing an operation, the user cannot perform that operation. The application disregards any grant records for the same node that allowed the user to perform the operation.

Deny Record Considerations

Deny records are rarely used. However, they do allow you to create exceptions to the current access rights. Keep these considerations in mind:

Deny records must precede grant records. The reason is that if the application finds a grant record that allows a user to perform an operation before it finds a deny record for the user, it stops looking at records for that node at that level. Thus, it allows the user to perform the operation.
Creating a grant record with no check boxes selected is not the same as creating a deny record with all the check boxes selected, although both stop users and groups from performing the same operations.
Group privileges can override either grant or deny records.

Deny Records for Projects

Before deleting a project from StarTeam, you may consider hiding it from the users. Creating one deny record at the project level for the All Users group (or for another umbrella group of users accessing the project) denies those users the access rights to see the project. It is essentially hidden from view and cannot be accessed for the group that has been denied.