Access Rights

This topic describes access rights, and rules and procedures for assigning or denying access rights.

Setting Access Rights

To grant access rights for an object or item, do the following:

Select the object or item in the client for which rights will be set:
- To set project access rights, the project must be open to any view.
- To set view access rights, the view must be open.
- To set folder access rights, select the folder from the folder hierarchy in the left pane.
- To set component access rights for public filters or queries, (for example, the change request component) bring the component tab into focus in the upper pane.
- To set individual file, change request, requirement, topic, or task item access rights, select the item from the upper pane.
Select Access Rights from the appropriate menu or context menu as follows:
- To set project-level access rights, select Project > Access Rights.
- To set view-level access rights, select View > Access Rights.
- To set folder-level access rights, right-click the folder on the Folder tab and choose Advanced > Access Rights.
- To set component-level access rights for public filters and queries, select the component type, (for example the Change Request menu) <Component Type> > Advanced > Component Access Rights.
- To set item-level access rights, select the item from the upper pane, and select <Component Type> > Advanced > Item Access Rights.
Click Add.

The Assign Access Rights To dialog box opens.
Select a user or group. Users are listed by their user names and groups are listed by their paths (excluding the All Users group).
Select Grant and click OK.
Caution: Never select Deny unless you are creating an exception. Deny records must be created before grant records.
Select/clear the appropriate check boxes. Selecting or clearing the check box for a category, such as Generic object rights for a project, selects or clears all the access right check boxes for that category. The category check box has only two states. When it is cleared, the access right check boxes for that category are either all cleared or mixed: some selected and some cleared.
Caution: Clicking Delete removes the selected user or group from the User and Groups list in the Access Rights dialog box. The selected user or group loses any previously set access rights to the Server.
Click OK.

General Access Rights Rules

The following rules should be kept in mind when granting or denying access rights:

Access rights can be overridden by the fact that a user is the object’s owner. Usually, the owner is the person who created the object.
Access rights can be overridden by privileges given to a group that includes the user. These privileges are set per group from the Server. By default, the Administrators group has full privileges (rights to do anything and everything).
Access rights should be set at the highest possible level.
The client checks for access rights from the lowest level (the item level) to the highest level (the project level).
If one grant record is created for a node, a grant record for that node should be created for every group that requires access to the project at that level. The Administrators group should have a grant record for each node, so that, if privileges are ignored, administrators can still change access rights.
If access rights are set for any user or group for a node, all users or groups without a grant record for that node will be denied all access rights at that level for that node.
Every view within a project has the same project-level access rights.
When you derive a child view from an existing view, the new view has no view-level access rights. However, folders and items in the child view that existed in the parent view retain the same folder-level or item-level access rights that they had in the parent view. Changing these access rights in either the parent or the child view also changes them in the other view because you are changing the rights on the same object. If the folders or items in either the parent view or the child view branch, they can have different access rights, because they are different objects.
Folders that are moved or shared from one view to another retain any access rights assigned to them at the folder level in the new view. However, if they branch, they lose their folder-level access rights.
Items that are moved or shared from one view to another retain any access rights assigned to them at the item level to the new view. However, if they branch, they lose their item-level access rights.
Avoid setting item-level access rights.
Avoid creating deny records. But if you deny rights, follow both of these rules: a) never allow any node on an Access Rights dialog to have only deny rights records, and b) verify that deny rights records for a node precede any grant rights records for the node.

Group Privileges and Access Rights

When users log onto a server configuration, they are identified individually by their user names and as members of the groups to which they belong. The application stores this information as an access token for each user. As users perform operations on application objects (projects, views, folders, and items), the application examines these tokens and the access rights for the objects on which the users are performing the operations. The application checks access rights in layers. The right to access an object begins with the System Policy dialog, which can be accessed from the Server Administration tool.

Unless group privileges are being ignored, these privileges also override and take precedence over rights configured elsewhere. Privileges are group properties set on the Privileges tab of the Group Properties dialog in the client. A user is granted the same privileges as those of the group to which he or she belongs. If the user belongs to two groups, and one is granted certain privileges while the other is denied the same privileges, the user is granted the privileges. The Membership tab of the My Account dialog displays the logged-on user's group membership information.

After consideration of group privileges, the application checks the access rights granted for specific objects. Settings on the Access Rights dialogs for projects, views, folders, and individual items grant or deny users or groups the ability to perform operations at those levels. It is important to remember that if access rights are granted to any user or group at a given level in an Access Rights dialog, users or groups who are not granted access rights at that level are effectively denied all rights.

Ultimately, if a user can see an object and is not stopped from performing an operation by a deny record, the user can do anything that a grant record allows, whether as an individual user or as a member of any group. The only exception has to do with privileges.

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.

Creating a Deny Record to Handle Access Right Exceptions

Suppose that you have a group called Testers that has complete access to the files in the QA view, a view that contains folders full of test files. A newly hired member of the Testers group, New Tester, has not yet been trained to update the tests, and so on. Although New Tester is a member of the Testers group, you do not want this user to perform certain operations on these files for a couple of weeks. You could remove New Tester from the Testers group temporarily, but the application also allows you to give New Tester all the rights of the Testers group with a few exceptions. To list the exceptions, you create a deny record.

To create a deny record to handle access right exceptions, do the following:

Click Add. The Assign Access Rights To dialog box opens.
Select a user or group. Users are listed by their user names and groups are listed by their paths (excluding the All Users group).
Select Deny and click OK to return to the Access Rights dialog box.
Caution: Never select Deny to create an exception to a group unless that group is already specifically granted access for this same node. In this example, the Testers group must have access for this node.
Select/clear the appropriate check boxes. Selecting or clearing the check box for a category, such as Generic object rights for a project, selects or clears all the access right check boxes for that category. The category check box has only two states. When it is cleared, the access right check boxes for that category are either all cleared or mixed: some selected and some cleared.

Caution: Clicking Delete removes the selected user or group from the User and Groups list in the Access Rights dialog box. The selected user or group loses any previously set access rights to the Server.
Click Move Up to move the deny record to the top of the Users and groups list in the Access Rights dialog box.
Tip: All deny records must precede all grant records in the Users and groups list. Otherwise, the exception will not occur. For example, if the application finds the grant record for Testers before it finds the deny record for New Tester, the rights the user has as a member of the Testers group will apply.
Click OK.