Granting Project-Level Access Rights

This section provides information about setting access rights at the project level. It illustrates this information by using an example with three user-defined groups: Developers, Testers, and Others. (These groups are in addition to the All Users, Administrators, System Managers, and Security Administrators groups that come with the StarTeam Server.) The example also assumes that the All Users group is larger that the Others group.

Project Node

Assume that you decide that only members of the Administrators group should control the project and create a grant record. This record prevents anyone who is not a member of the Administrators group from seeing the project, unless privileges apply. As a result, no one else can access and work with the objects in this project.

Note: Although members of the Administrators group require all access rights for the project, you may decide to omit them from the Users and Groups list if they have group privileges. Normally, this is acceptable. However, if the server configuration is set to ignore privileges, you must specifically grant the Administrators group all project access rights.

Next, you must assign the correct rights to the every other group that needs to access this project. Because keyword expansion is a project property, the Developers group needs to have the rights to see the project and modify its properties. However, they probably do not need to delete the project or change its access rights. The Testers and Others groups need to see the project and its properties, so you should select only the See Object And Its Properties check box for these groups.

View Node

View access rights at the project level apply to all views that now exist or will be created for this project in the future. Members of the Administrators group need all view rights. They may be assigned these rights or receive them because of their privileges. The Developers and Testers groups need to see and modify view properties and perform operations on labels. They do not need to create or delete views, manage promotion states, or change view access rights. The Others group needs to see the view, but requires no other rights.

Promotion State Node

The Promotion State node is not important in this example.

Child Folders Node

For access rights to child folders at the project level, the Administrators group may need all rights. They may be assigned these rights or receive them because of their privileges. The Developers and Testers groups probably do not need to delete folders, share or move folders, change folder behaviors or configurations, or change folder access rights. You may want the Others group to only see the folders, their properties, and their histories.

Item Nodes

We do not recommend creating only one grant or deny record for a given node. The following section illustrates how project-level item access rights work, using files as an example.

If only the developers need to access files, you can grant only the Developers group all file access rights at the project level.

With this setting, only members of the Developers group have access rights to any files, regardless of the view, folder, or file. As a result, only developers can see or perform operations on any files. Members of the Testers and Others groups see only the files that they have in working folders, but the status of these files appears as Not In View. However, by default, one exception exists by using Privileges. If groups other than the Developers have one or more privileges that allow them to see, modify, define, or perform other actions on a file, members of those groups have access to the files regardless of the access rights settings. For example, the default settings for the Administrators group grant all privileges to this group. Therefore, members of this group can perform any file operations.

You can stop the server configuration from checking for privileges.

If you give only the Testers and Developers groups access to other types of items (change requests, requirements, tasks, and topics), the same exceptions apply. However, other groups will want to see these types of items, so you will need to grant these groups some access rights.