How do site administrator roles work?

Site administrators are default site managers who can create additional site administrators and delegate few site administrative tasks to them. They can also allow some CollabNet TeamForge users to use one or more CollabNet TeamForge tools across several projects, by creating site-wide roles with specific project permissions, minus site administrative permissions. They can also provide ready-to-use roles as global roles, creating uniformity across the site.

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.

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 project 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.

Site Administration Responsibilities

The additional site administrators can be granted administrative rights for any of the site administrator responsibilities related to the following:

Projects (includes project templates)
Project Groups
Users
Groups
Roles
Categories
System Tools
Integrated Applications

Site Administration Permissions

View Only: Allows users to view and download items, but not to create or edit items, administer or edit application settings.
Create or Submit: Allows users to create or submit and edit items, but not to administer or edit application settings. Users with the create or submit permission also have the edit and view permissions.
Edit: Allows users to edit items, but not to administer items or edit application settings. Users with the edit permission also have the create / submit and view permissions.
Administer: Allows users to create, edit and administer items plus edit application settings, if required. 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 items or edit application settings. Users with the delete permission also have view permissions.