Assigning Rights to Projects

Project-level settings define access rights for all views, child folders, and items in the project. A user will not be able to open a project if you deny any of the following to a user or to all the groups to which the user belongs:

• The ability to see the project.
• The ability to see the initial (or root) view of the project.
• The ability to see the root folder of the initial view of the project.

In this topic:

Assigning Project-Level Access Rights

To assign access rights to a project, do the following:

1. Open the project and select Project > Access Rights.

   The Project Access Rights dialog box opens.

2. Select a node. It is best to start with the Project node and work down.

3. Click Add to add a user or group.

   The Assign Access Rights To dialog box opens.

4. Select a user or group. Users are listed by their user names and groups are listed by their position in the group hierarchy, except for the All Users group.
5. Select the Grant option button.

   Note: Never select the Deny option button unless you are creating an exception.

6. Click OK.
7. Select/clear the appropriate check boxes for the user or group.
8. Repeat steps 3-7 as required for additional nodes

Back to top

Granting Project-Level Access Rights Examples

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.

Back to top

Generic Project Access Rights

To display the Project Access Rights dialog, select the Project > Access Rights command. The right to create a project is set as a server access right.

The following table describes the generic object rights for a project.

See object and its properties	See this project and view its properties by selecting Project > Properties.
Modify properties	Change the properties for this project. The project properties that can be modified are name, description, keyword expansions settings, alternate property editor (APE) settings, process rules settings, requiring unlocked files to be read-only, and several settings that affect users (for example, requiring revision comments to be entered when a file is checked in).
Delete object	Delete this project from its server configuration.
Change object access rights	Change the access rights for this project. If you change this setting, be sure that you remain one of the users who can change access rights.

Back to top