Share this page
Granting View-Level Access Rights
This topic presents the guidelines for granting view-level access rights, and describes the View access rights.
View-Level Access Rights
Usually, granting access rights at the project level is not a fine enough level of granularity. For example, one set of developers may maintain Release 1.0 of the product in one view, while another set of developers writes the source code for Release 2.0 in another view.
To handle this situation, you may want to create new groups, such as 1.0 Developers, 2.0 Developers, 1.0 Testers, and 2.0 Testers. You can give the 1.0 Developers and 1.0 Testers access to files and/or change requests in the Release 1.0 view and. Then you can give the 2.0 Developers and 2.0 Testers access to files and/or change requests in the Release 2.0 view.
In this case, you need to set access rights at the view level. However, you must still set project access rights at the project level because that is the only place where the Project node appears.
| View and Child View Access Rights |
Access rights in a child view at the view level are independent of the access rights of the parent view at the view level. Therefore, a child view starts out with no access rights at the view level. A new child view is represented by a different object in the repository from the parent view. It has a different name, description, place in the view hierarchy, etc. View-level access rights can be set for a new child view. For example, suppose a reference view contains only one branch of the parent view’s folder hierarchy. The reference view has a root folder named QA Tests. In this situation, you can make the Testers the only group with file access rights in the reference view, even if Developers is the only group that has file access rights in the parent view. |
| Access Rights at Different Levels |
Sometimes a group has different access rights at the view and the project levels for the same type of object in the same view. In this situation, the access rights at the lowest level are enforced. When the StarTeam Server searches for access rights, it starts from the lowest level and moves to the highest level. When it finds a level at which a group has access rights, it does not search any higher levels for that type of object. Remember that the project access rights exist only at the project level, so the project level is always searched for these rights. File access rights, on the other hand, exist at the file, folder, view, and project levels. the server stops at the first level at which it finds file access rights. |
View Access Rights
When you select the View > Access Rights command to open the View Access Rights dialog box, the rights shown are for the current view. The rights available from the View node are also available from the View node in the Project Access Rights dialog box. In the latter case, the rights cover all views in the project rather than an individual view. It also include a container-level right that allows users or groups to create views for the project. This right is not available on the View node of the View Access Rights dialog box.
The following table describes the access rights that are available from the View node in the Project Access Rights dialog box. Most of these access rights also appear on the View node of the View Access Rights dialog box, but apply only to the current view.
Generic Object Rights
| See object and its properties |
Change view properties. View properties that can be modified are the view’s name, description, working folder (also the root folder’s working folder), branch setting for shared items, and file status repository setting. |
| Modify properties |
Modifies the view properties. |
| Delete object |
Deletes the object from the view. |
| Change object access rights |
Changes the access rights of the selected object in the view. |
View-Specific Rights
| Create view labels |
Creates view labels. These labels will be automatically attached to the folders and items in the view. Users with this right but not the right to attach labels can still create labels. |
| Modify view labels |
Changes the properties of view labels. For example, this right allows a user to freeze labels so that they cannot be adjusted |
| Delete view labels |
Deletes view labels. This action automatically detaches the view labels from the folders and items that had the labels. Users with this right but not the right to detach view labels can still delete view labels. |
| Create revision labels |
Creates revision labels. Users with this right but not the right to attach labels can still create labels. |
| Modify revision labels |
Changes the properties of revision labels. For example, this right allows a user to freeze labels so that they cannot be adjusted. |
| Delete revision labels |
Deletes revision labels. This action automatically detaches the labels from the folders and items that had those labels. Users with this right but not the right to detach revision labels can still delete revision labels. |
| Define promotion model |
Creates, deletes, and reorders promotion states and edit their properties. After creating a promotion state, you must exit and reenter the Promotion dialog if you want to set access rights for the newly created state. |
| Override default types | Overrides default types. |
Generic Object Container Rights
| Create views |
Creates views in the current project. This container-level right is available only when you select the View node from the Project Access Rights dialog. |
| Override default types |
Allows users to override the default set of types included when a new view is created. |
