To control who can access your project, consider the purpose of your project and the appropriate type of user.

Control Access by User Role

Project administrators use existing global project roles or create and assign roles to project members to define what those project members can do in the project.

If you choose to use existing global project roles, you can quickly assign relevant roles to your project members. It is a good practice to create a new role in your project only when a suitable global project role is not available.

Create a User Role

A role defines the applications that project members with that role can use, and the specific things project members can do in each application.

Any project administrator can create and assign a role.

  1. Click PROJECT ADMIN from the Project Home menu.

  2. On the Project Admin Menu, click Permissions.

  3. On the ROLES tab, select View: Roles Created For a Project.

  4. Click Create.

  5. On the Create Role page, write a name and description for the role.

  6. To let this role be automatically added to any private subprojects of this project, clear the PREVENT INHERITANCE option.

    By default, roles are inherited by public and gated subprojects, but not private subprojects.

  7. To allow project members to be able to request this role, select PROJECT MEMBERS CAN REQUEST THIS ROLE. Project members can submit requests for requestable roles, which the project administrator can approve or reject.

  8. Click Create. The role is created. The Edit Role page appears.

  9. For each application listed on the Role Permissions page, select the permissions and resources you want to make available to users with this role.

  10. Click Save.

The role is created. You can assign it to project members at any time.

Create a Project Administrator Role

The project administrator is responsible for managing the project’s users and roles.

The project creator is assigned the Founder Project Admin role, a special role granting all project and application administration permissions for the project. You can transfer the Founder Project Admin role to another user.

If the project creator is a CollabNet TeamForge administrator, no Founder Project Admin is created.

  1. On the Role Permissions page, select Project Admin Permissions.

    • If you want the role to contain only the project administrator permissions to manage users and roles, Project Admin Permissions is all you need to select.

    • If you want the role to contain additional application administration or other permissions, check the additional permissions.

  2. Click Save.

All project members assigned this role have project administrator permissions to manage the project’s users and roles.

Change a Role

If users need to do things that are not allowed by a role you have assigned to them, you may need to change the permissions associated with that role.

When you edit a role, all project members with that role get the updated permissions automatically.

  1. Click PROJECT ADMIN from the Project Home menu.

  2. On the Project Admin menu, click Permissions.

  3. From the list of roles created for this project, click the role you want to edit.

  4. On the Role page, make the changes you need.

    • To edit the title or other role details, click Edit. Make the required changes and click Update.

    • To edit the role’s permissions, choose an application from the left side of the page and select or deselect permissions and resources.

    • To edit the project members to whom the role is assigned, click Assigned Project Members.

    • To edit the user groups to whom the role is assigned, click Assigned Groups.

  5. Click Save.

The role is modified.

Give Roles to a Project Member

A project member can have any number of roles. As project administrator, you must assign each project member’s roles.

Permissions are cumulative. The project member has all of the access permissions allowed by all of the assigned roles, plus any permissions that may have been assigned globally using application permissions.

  1. Click PROJECT ADMIN from the Project Home menu.

  2. On the Project Admin Menu, click Permissions, then click the User-Role Matrix tab. Observe the users listed on the left and all the available roles (global, direct and inherited) on the right.

    Users can be assigned global, direct and inherited roles. Inherited users have all the permissions that they have in the parent project.

    If you assign another inherited role to an inherited user, that user gets both the roles.

    If you assign a role to a user in a project, that user becomes a current member in that project.
  3. Select roles for each project member.

    The USER_ROLE MATRIX page is also equipped with a smart search (filter) function that makes it easy to filter a user by name and assign roles. Use it to quickly search for a user to which you want to assign one or more roles.

  4. Click Save.

The roles are now assigned to each project member.

Give a Role to Multiple Project Members

A role can be assigned to many users at once.

The user-role matrix provides a convenient way to add project members to a role, but it can become unwieldy if the project has a large number of users or roles. When that is the case, try assigning roles to multiple users at one time.

  1. Click PROJECT ADMIN from the Project Home menu.

  2. On the Project Admin Menu, click Permissions.

  3. Click the name of the role that you want to assign to project members.

  4. On the Role Permissions page, click the Assigned Project Members tab. The Assigned Project Members page shows all users who currently have the role.

  5. Click Add and use the Find a User window to move your desired users into the Selected Users list.

  6. Click OK.

The project members are now assigned the role.

Handle a Role Request from a Project Member

A project member in CollabNet TeamForge can ask to be granted a role. As the project administrator, it’s up to you to approve or reject such requests.

When a CollabNet TeamForge project member submits a request for a role in a project, the request is placed in the User Membership section of the Project Administration page, pending approval by a project administrator. The request is also displayed in the Items Pending My Approval section of each project administrator’s My Page.

  1. Click PROJECT ADMIN from the Project Home menu.

  2. On the Project Admin Menu, click User Membership, then click the Pending Requests tab.

  3. Under Role Requests, select the user whose role request you want to approve or reject.

    • Click Approve to approve the request and assign the role to the user.

    • Click Reject to deny the request.

The user receives an email notification when the request is approved or rejected.

Assign a Global Project Role on Request

As a project administrator you can edit a requestable global project role for your project. You can update the settings to immediately assign the role to a project member on request.

  1. Click PROJECT ADMIN from the Project Home menu.

  2. On the Project Admin Menu, click Permissions.

  3. From the list of global project roles, click the requestable global project role you want to edit.

  4. On the Edit Role page, click Edit.

  5. Select the Grant Automatically on Request option and click Save. Selecting this option enables the project member requesting the role to be assigned the same immediately, without waiting for an approval.

The role is modified for your project.

Assign Roles to a User Group

Enable multiple users to do something all at once by giving their group a role.

A user group can have any number of roles. Each member of the user group has all the access permissions allowed by all of the assigned roles, plus any permissions that may have been assigned by other methods, such as application permissions or individually assigned roles.

Roles and the associated permissions can be inherited. If your project is a subproject of any other project, you may have inherited some roles or user groups. You can assign any inherited role to any user group.

  1. Click PROJECT ADMIN from the Project Home menu.

  2. On the Project Admin menu, click Permissions, then click the Group-Role Matrix tab. Observe the user groups listed on the left and all the available roles (global, direct and inherited) on the right.

    User groups can be assigned global, direct and inherited roles. The inherited user groups have all the permissions that they have in the parent project.

    If you assign another inherited role to an inherited group, the members of that group get both the roles.

    If you assign a role to a user group in a project, that user group becomes a direct user group in that project.
  3. Select the roles you want for each user group and click Save.

The roles are now assigned to each user group.

Assign User Groups to a Role

To manage permissions for a lot of groups or roles at once, try assigning user groups to roles.

  1. Click PROJECT ADMIN from the Project Home menu.

  2. On the Project Admin Menu, click Permissions.

  3. To display existing global, direct or inherited roles, click the Global project roles, Roles Created For a Project or Roles Inherited From Parent Project option of View.

    You can assign direct user groups to a global/direct/inherited role.

  4. Click the name of the role that you want to assign to user groups.

  5. On the Role Permissions page, click the Assigned Groups tab. The Assigned Groups page shows all user groups that are currently assigned the role.

  6. Click Add.

  7. Type some of the group’s name in the Name (search) box and click Find.

  8. In the Find a user group window, select the user groups that you want to add, and click Finish.

The user groups are now assigned the role.

View Users and User Groups Assigned to a Role

Before adding a role to a project member or user groups, see all the users and user groups who are assigned that role through inheritance.

A user or user group can have any number of roles. Roles and the associated permissions can be inherited via project hierarchy or project groups.

  1. Click Project Admin from the Project Home menu.

  2. On the Project Admin menu, click Permissions.

  3. In the View drop-down, select Global project roles and from the results, a specific role.

  4. In the Assigned Project Members tab, click the View drop-down and make a selection.

    • Direct Members displays the users who are directly assigned the role in the project.

    • Inherited Members displays the users who inherit the role from parent projects as well as project groups.

  5. In the Assigned Groups tab, click the View drop-down and make a selection.

    • Direct User Groups displays the user groups that are directly assigned the role in the project.

    • Inherited User Groups displays the user groups that inherit the role from parent projects as well as project groups.

The roles are now assigned to each user group.

Control Access by User Class

To avoid having to create and assign a lot of similar roles for individual users, give access to applications to whole classes of users whenever possible.

For each application (tasks, documents, file releases, trackers, and discussion forums), you can assign permissions globally based on user type.

For example, if you know that you want all project members to be able to view and submit to all project trackers, set the application’s permissions to reflect this. You need to configure these settings only once.

  1. Click PROJECT ADMIN from the Project Home menu.

  2. On the Project Admin page, configure your project access settings and click Next.

  3. On the Edit Default Access Application Permissions page, click the + symbol to expand the section for which you want to assign permissions.

  4. For each application and resource, choose a user type from the drop-down menus.

    • All users of the selected type will have the specified permissions: view, submit/view, or post/view.

    • For discussion forums and trackers, you can also specify submit or post permissions.

  5. Click Finish.

Control Access by Project Type

Projects can be open only to project members, open to everyone in the world, or something in between.

By default, all new projects are created as private projects, accessible only to project members. Your system administrator can change the default access level for new projects.

  1. Click PROJECT ADMIN from the Project Home menu.

  2. On the Project Admin Menu, click Permissions, then click the DEFAULT ACCESS PERMISSIONS tab to see the project’s current access setting.

  3. Click Edit.

  4. On the Edit Default Access Permissions page, select the kind of access you want to allow to your project.

    • Private - Project members only.

    • Gated community - Project members and unrestricted users.

    • Public - All users.

Allow Users to See Other Users’ Roles

You can enable some project members to view the roles assigned to other project members.

For example, if your project includes both core team members and consultants, you may want to restrict full visibility of user details to the core team members.

  1. Click PROJECT ADMIN from the Project Home menu.

  2. On the Project Admin Menu, click Permissions.

  3. On the ROLES tab, click the role you want to edit. For example, if you have divided project members into a “Core Team” role and a “Consultant” role, click the “Core Team” role.

  4. Under Project Admin Permissions, select View User Membership.

Now only project members who have the role you edited can see the roles held by other project members.

Lock or Unlock a Project

To ensure that no changes occur in a project while you are collating or migrating project data, lock the project. You must have project administration permissions or be a site administrator to lock or unlock a project.

To lock or unlock a project in TeamForge, go to Project Settings and lock/unlock the project.

Click PROJECT ADMIN from the Project Home menu.

The project is locked or unlocked as desired. The lock ( ) icon appears on all the project pages while the project is locked.

Control Access to Source Code

It’s a good idea to make sure your source code can only be used by people who have business with it.

You can control which users can view or commit source code. You can make these distinctions at the repository level or at the path level within a repository.

  1. Click PROJECT ADMIN from the Project Home menu.

  2. On the Project Settings page, click Permissions.

  3. Click the role whose access to source code you want to control.

  4. On the Edit Role page, click Source Code.

  5. Under Permissions for Specific Repositories, select a repository in the project and specify this role’s access to the repository as a whole.

    • To block users with this role from seeing this repository at all, select No Access.

    • To allow users with this role to see everything in the repository but not commit to it, select View Only.

    • To allow users with this role to commit to any path in the repository, select View and Commit.

  6. If you want to control access to a specific path within the repository for users with this role, select Path-based Permissions (PBP).

    See Who can Access Source Code? and Wildcard-based access control and path-based permissions (PBP) in TeamForge for more information.

    1. Click Add.

    2. Specify a path in the repository.

    3. Select No Access, View Only, or View and Commit for this path.

      If none of the available permissions (View Only, View and Commit, or Path-based Permissions) is selected for any repository, and none of the options under Source Code Permissions is selected, users with this role do not see the Source Code toolbar button.

      If two paths have different permissions, the permissions on the lower-level path take effect. For example, consider a role that has “No Access” set for the path /branches/version3/users, but has “View and Commit” access to /branches/version3/users/vijay.

      Users with this role can:

                Check code in and out of the vijay directory.

                Click down through all the directories in that path, including users.

      Users with this role cannot check files in and out of the users directory or monitor commits to users.
  7. Click Save.

Control HTML Headers in Hand-coded Project Pages

When a HTML page that you created in Microsoft Word or Frontpage looks strange, you may be able to fix it by suppressing HTML head content.

  1. Click PROJECT ADMIN from the Project Home menu.

  2. On the Project Settings section, select Show custom web page and then select Preserve HTML head content.

  3. Click Save.

Pages created in Microsoft Word or Frontpage should render correctly.

Allow Anonymous Subversion Checkouts

To grant anonymous checkout access while restricting write access to a Subversion repository, set the project’s default access permissions to public, provide Source Code View permission to all users, and limit other permissions to specific user classes.

  1. Click PROJECT ADMIN from the Project Home menu.

  2. On the Project Admin Menu, click Permissions, then the DEFAULT ACCESS PERMISSIONS tab.

  3. Under Application Permissions, choose All users from the drop-down for Source Code View permission.

  4. For other application permissions, choose a user class based on your access requirement.

Users can now check out from a repository without entering a password.

Show or Hide an Application

To help users focus on the relevant parts of your project, choose which applications they can see in the Project Home menu.

  1. Click PROJECT ADMIN from the Project Home menu.

  2. On the Project Admin Menu page, click Tools.

  3. Select the applications that you want to be visible to users in your project, and click Save.

Only the application buttons you have set to VISIBLE appear in the Project Home menu of the project page.

  • Removing buttons from this menu does not remove the application from the site. Users with the appropriate permissions can still get to the hidden applications by other means, such as clicking a link in an email. The hidden application button will not appear.

  • When an application button is set to Visible, but a given user does not have permission to use that application, that user still cannot see the application button. For example, if a user has a role that does not permit access to any source code repositories, that user does not see the Source Code toolbar button, even if the button is enabled for the project.

  • If the Tasks tool is hidden for a project, the option to run reports on the Task tool is also hidden.

  • If you create a project template from a project that has hidden applications, any project you create from that template will have the same applications hidden.

Limit User Posts to Discussions by Email

To help reduce the risk of spam or other mischief, you may need to limit the users who can post to your project’s discussion forums by email.

To leverage the advantages of community collaboration, you should keep your forums as open as you can. However, some projects require tighter control over who can participate in discussions. TeamForge enables you to balance openness against privacy along a spectrum of choices.

  1. Click PROJECT ADMIN from the Project Home menu.

  2. Click Discussion Settings.

  3. Set the value of EMAIL POSTING to one of these choices (listed from most restrictive to least restrictive).

This option... has this effect
Allow only forum admins Only users with the "discussion admin" permission can post by email.
Users with roles & permissions Only registered users with the "topic post" permission can post by email. This is the default. (For discussions marked as private, this is the least restrictive setting possible.)
All logged in users All users who are registered on the site can post by email.
Allow known email addresses only Users can post by email only if they have explicitly been added to the monitoring list. (This can include people who are not registered site users.)
All site users and guests Anyone can post by email.

If you select a value that’s more liberal than the value your site administrator has set for the site as a whole, the site administrator’s setting rules. For example, suppose the site administrator has provided that only users with the appropriate role (“Users with roles & permissions”) can post by email. If your project requires extra security, you can choose to accept email only from forum administrators. However, you cannot accept email posts from a less restrictive category of users, such as “All logged in users.”