Projects, Roles, Groups, Members and Users

CodeBeamer operates with User Accounts. A User must have an account to log in. An account can be created manually from the New Account dialog or by the LDAP authentication system at the first login.

Projects

CodeBeamer data is organized into projects. Projects are secure collaborative workplaces where users can share, discuss, contribute, coordinate and find project information. A registered CodeBeamer user can create projects provided they have sufficient group permissions. When a user creates a project, the Project Administrator role is assigned to that user. Typically the project administrator is responsible for managing project resources. See also Authentication and Access Control in codeBeamer , Managing Projects

Managing Large Numbers of Projects

When working with many projects, it is useful to sort related projects into Working Sets. Projects could be grouped according to line of business, or functions such as Research and Development or Finance. Please see Project Groups for more details.

Projects and Working Sets of projects can be selected from a menu that appears when the cursor hovers over the Project Menu-bar item. This type of menu is called a 'tool-tip' menu. The five most-recent projects are displayed.

Users

Watch a video on roles and groups here.

A user is an individual (or application program using the API) identity that has a codeBeamer account. A codeBeamer user can have a set of roles in a project , which entitles that user to access all resources allowed by those roles. Users are also associated with a group, which specifies a different set of permissions, which apply in all projects.

Accounts

An account is used to identify a user by name, and password. Account information contains data such as name, organization, e-mail, skill, etc.

Members

A user who is assigned to a project is a project member. A member can be assigned to one or more projects and to one or more roles.

Roles

Roles reflect hierarchical or task-based team structures in a project. A role's access permission's scope is project-wide. For example a role can be Developer or Designer where users in the Developer role are granted write access on the SCM system but users in the Designer role are not.

Custom Roles

Custom roles are useful when the standard codeBeamer roles (Customer, Developer - Extern, Developer - Intern, Stakeholder) are insufficient to organize your team structure, and you need a new role e.g. Architect, with specific access privileges. Roles' permissions and custom roles are specific to the project in which they are created. Custom roles can be created and default, standard roles can be edited in any project, assuming the role-editor has sufficient permissions on the project.

If you create a new role in an existing project, without using a template for the new role, the new role will not have permissions for any project artifacts created before the role. So for example, Trackers that existed before the role was created will not be visible to the new role, even though you selected the 'Tracker -View' permission when making the new role. Only new Trackers, created after the role is created, will be visible to it. If you desire your new role to have access to existing project areas, you must manually add the permissions in each area (Trackers, Document Manager, and so on). To check the permissions of your newly-created role, add a member to the role, and use the tooltip menu next to the member's name in the Members area of the project to determine the granted permissions. We recommend using a template role, instead of manually adding permissions.

Groups

A group is a collection of users. Groups can represent organizational structure. The scope of group permissions is server-wide. A codeBeamer group is a category of users classified by common traits, such as organization, job profile, skill or title. For example, at a software development organization a user might belong to the Customer group, but other users to the Developer, Support, or Management groups. Categorizing users into groups makes it easier to control the access of medium to large numbers of users.

With the group structure you can collect users on the codeBeamer server into logical sets, and assign them different sever-wide permissions such as project-creation permissions or permissions to view other users' personal data. Groups can only be administered by the System Administrator, see Managing Groups.

Assign Roles to Groups

Groups can also be assigned different roles in different projects. This makes the management of access rights very convenient, especially when a large number of users must be managed.

Roles are administered in each project by the Project Administrator. A role's access to project information is defined by the Project Administrator on the Members tab, by selecting the 'edit' option for the role on the left-hand side panel.

Role Based Access Control

Roles allow control of visibility and access to various codeBeamer artifacts, like trackers, reports or documents. This ensures for example that both internal teams and business partners only see and access appropriate information. Members of the same role have the same level of access to artifacts on projects. The highest level of access permission a member has from individual roles or groups takes precedence when accessing an artifact.

For tracker, document and Wiki artifacts, a fine granulated access-permission mechanism is provided on Trackers, Work items, attachments, comments, associations and notifications.

Role and Group Based Access Control

Role and Group Based Access Control is useful to manage access control for medium or large numbers of users. Role and Group Based Access Control is also useful to simplify the project setup and management if:

• users are not exactly known at the project set-up,
• the number of users changes frequently in a project or
• communities or anonymous access must be managed

When the individual developers and testers are partially or not known at the project setup, you can

1. create the groups Developer, Tester and TechWriter (SysAdmin function)
2. create the roles Developer-access, Tester-access, TechWriter-access
3. edit the access permissions for the roles
4. assign the group Developer, to the role Developer-access
5. assign the group Tester, to the role Tester-access
6. assign the group TechWriter, to the role TechWriter-access

When your organization has many new customers and their number is growing or changing rapidly, you can

1. create a group Customers and
2. assign the group Customers to a Customer-access role on specific projects.

See also Building Communities Around Your Projects and Administering Projects

User membership diagram

Item visibility control

If a user would like to see a Tracker Item then codebeamer has to check the permissions on multiple level:

• User should be a member of the Project of the Tracker Item (directly or indirectly)
• User should be member of a Role which have View if Owner or View Any permission on the Tracker of the Tracker Item (directly or indirectly)
• If the permission was only View if Owner then it is necessary to check the following fields:
  • submittedBy, assignedTo, supervisor, team
  • User has to be set to one of the previous field directly (for example: assignedTo field contains the User) or indirectly (the value of assignedTo field is a Role and the User is member of that Role)

Permission Control through Team Assignment

Item visibility Control through Team field since 10.0

The Team field is a built-in field in codeBeamer's trackers which can be hold references to tracker items in Team trackers. These references are going to be used automatically in item visibility logic.

To check the accessibility codeBeamer is using the assignedTo(Team members) field of the referred item.

For example:

Task tracker - View if owner permission for Developer role

A user who are member of the Developer role can see the items in the Task tracker through assignedTo and team fields if:

• user was set to assignedTo field directly
• Developer role was set to assignedTo field
• Group was set to assignedTo field and the user is member of the group and the group is member of Developer role
• Team was set to team field and the user is member of Team directly or indirectly and the user is member of the Developer role directly or indirectly

So item is not visible for test user with the following configuration:

Item is visible after team assignment:

Field and Item visibility control through Team assignment

To manage team members’ permissions in codeBeamer, users must add the team members to a participant field on the work item.

Adding can be done either manually or through calculation:

distinct(teams.{team|team.assignedTo.{member|member}})

The reason for this procedure is that teams are tracker objects and codeBeamer’s permission assignment mechanisms do not deal with objects when defining permission through participant fields or roles.

In this example, the project configuration contains a Software Task (Task type) and a Team (Team type, Tracker Key: Team).

Team

an upstream reference to the Software Task through the Team attribute (property name: teams):

In this example there are two teams, Team A and Team B, each team has two team members:

-

codeBeamer users need to pull team members into a Member field on the work item to manage their permissions.

1. Create a new Team Member field for this purpose.

Any default Member type field could be used for this purpose, considering that calculated fields are not directly editable on the work item.

2. Enable permission configuration through the new member field.

3. Configure auto-populate the Team Member(s) through the Team assignment.

Add the below calculation:

distinct(teams.{team|team.assignedTo.{member|member}})

where

teams Team field’s property name in the Task tracker,

team Team tracker’s Key and

assignedTo property name of the attribute where we assign the team members the to teams.

Save the configuration.

4. Verify that the process works and Team Member(s) field is autopopulated correctly.

When you make a new team assignment made on a Software Task, team members are automatically added to the Software Task’s Team Member(s) field: