Project administrators can define specific access permissions for individual project
members. They do this by using global roles and/or creating roles and assigning the roles to
project members.
Under role-based access control (RBAC), permissions are not assigned directly to an
individual user. Instead, each user has the permissions that are attached to any role
that is assigned to that user.
A project member can be assigned multiple roles.
In CollabNet
TeamForge, site or project
administrators assign roles to the site users or project members. Besides this, a
project member can submit a role request to the project administrator. The project
administrator can approve or reject such requests.
When you define users, user groups and roles with specific permissions
in one project, they can be inherited in one or more subprojects. This helps you avoid
duplicating the effort of defining users, user groups and roles across projects.
Note: Permissions are cumulative. If a project member is assigned a role that provides a
specific permission, and another role that does not, the user has that
permission.
A role defines these things:
- The applications that project members with that role can and cannot access.
- The resources on which project members with that role can use the applications.
- The actions that project members can take in each application and on each
resource.
When a user's roles do not include access to an application or resource, that application
or resource is not visible to that user. For example, imagine that you are assigning
roles to Jason, a software developer. Jason needs to check source code in and out in
order to fix bugs, develop features and create software releases. However, Jason does
not need access to the wiki. If you set up Jason's roles according to those
requirements, Jason's experience is like this:
- On any page in the project site, Jason can see and click the
Tracker, Source Code, and
File Releases buttons along the top of his screen.
- Jason does not see the Wiki button.
- If someone sends Jason a link to a page in the Wiki application and Jason clicks the
link, he gets an error message. (The message does not specify whether the page
exists or not.)
- When he accesses the project directly from Eclipse or Visual Studio, Jason can
expand the project node and browse the Tracker,
Source Code, and File Releases
nodes, but not the Wiki node.
Applications
An application is a collection of related features designed to enable a user to
perform tasks and collaborate with other users. For example, the Documents
application helps users create documents, share in document reviews, and publish
documents, among other things.
In the Web interface, each application is represented by a button in the navigation
bar at the top of any project page. A given user can see the buttons corresponding
to applications they have access to by virtue of the roles assigned to them.
Applications are also known as "tools."
Resources
- The tracker application might contain a bugs tracker and a feature request
tracker. These are the tracker resources.
- A project can contain multiple SCM repositories. These are the SCM
resources.
Permissions
- View
- Allows users to view and download items, but not to create or edit items,
administer folders, or edit application settings.
- Create or Submit
- Allows users to create new items, but not to edit items, administer folders,
or edit application settings. Users with the create or submit permission
also have the view permission.
- Edit
- Allows users to edit items, but not to administer folders or edit
application settings. Users with the edit permission also have the view
permissions.
- Administer
- Allows users to create and edit items, administer folders, and edit
application settings. Users with the administer permission also have the
edit, create or submit, and view permissions.
- Delete
- Allows users to delete items, but not to administer folders or edit
application settings. Users with the delete permission also have view
permissions.