Basics: Projects, Roles, Groups, Members and Users
A user account can be created manually from the New Account window or by the LDAP authentication system at the first user 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 if 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.
Managing a Large Number of Projects
When working with many projects, it is useful to sort related projects into Working Sets. Projects could be grouped according to the business type, or functions , such as Research and Development or Finance. Refer Project Groups for more details.
Projects and Working Sets of projects can be selected from a menu that appears when the pointer hovers over the Project menubar item. The five most-recent projects are displayed.
Users
A user is an individual identity (or application program using. an 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 that specifies a different set of permissions that apply to all projects.
Accounts
An account is used to identify a user by the name and password. Account information contains the user data such as name, organization, email, skill and so on.
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. The role has a project-specific permission access. For example, a role can be Developer or Designer, where users in the Developer role are granted write access on the Software Content Management 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, or Stakeholder) are insufficient to organize your team’s structure, and you may need a new role, for example , Architect, with specific access privileges. Roles' permissions and custom roles are specific to the project in which they are created. You can create custom roles and edit default, standard roles if you have sufficient permissions on the project.
To create a custom role:
1. Click 
on the Admin tab and select Members. The Members window opens. .
on the Admin tab and select Members. The Members window opens. .2. Click the Add Role hyperlink on the top left side of the screen. The Create New Role window opens.
3. Enter the details such as Role, Description and then select the required permissions for the new role.
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 to any project artifacts that have been created before the role was added . 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 that are created after the role was added will be visible to it. If you want your new role to have access to the 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.
 | A better practice is to use a template role instead of manually adding permissions. |
Groups
A group is a collection of users. Groups can represent the organizational structure. The scope of group permissions is server wide. A Codebeamer group is a category of users classified by common chracteristics, such as organization, job profile, skill or title. For example, at a software development organization a user can belong to the Customer group, but other users can belong to the Developer, Support, or Management groups. Categorizing users into groups makes it easier to control access for a large number 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 managing access rights for large numbers of users more efficient .
Roles are administered in each project by the Project Administrator. A role's access to the project information is defined by the Project Administrator. To define a role for a member or to add a new member or a new group, click the on the Admin tab and select Members. The Members window opens. In this window, you can add new roles as well as manage the existing roles for the projects to which you have access.
on the Admin tab and select Members. The Members window opens. In this window, you can add new roles as well as manage the existing roles for the projects to which you have access.Role Based Access Control
Roles allow control of visibility and access to various Codebeamer artifacts, such as trackers, reports, or documents. For example, this can ensure that both internal teams and business partners see and access only appropriate information. Members of the same role have the same level of access to artifacts on projects. The highest level of access permission that a member has for the individual role or group takes precedence when accessing an artifact.
For a tracker, document, and wiki artifacts, a finely detailed 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 for managing access control for medium or large numbers of users. Role and group based access control is also useful for simplifying the project setup and management for the following conditions :
• Users are not well known at the project setup.
• The number of users changes frequently in a project.
• The communities or anonymous access must be managed.
When the individual developers and testers are partially or not known at the project setup, you can do the following :
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 is changing rapidly, you can do the following :
1. Create a group Customers.
2. Assign the group Customers to a Customer-access role on specific projects.
User membership diagram
Item Visibility Control
If a user wants to see a Tracker Item Codebeamer must check permissions on multiple levels:
• The user must be a member of the Project of the Tracker Item , directly or indirectly.
• The user must be member of a Role that has a View if Owner or View Any permission on the Tracker of the Tracker Item, directly or indirectly.
• If the permission is only View if Owner, then you must select the following fields:
◦ submittedBy, assignedTo, supervisor, team.
◦ The user must be set to one of the previous fields directly (for example, the assignedTo field contains the user) or indirectly (for example,the value of assignedTo field is a role and the user is member of that role).
Permission Control through the Team Assignment
Controlling the Item Visibility Using the Team Field Starting with Codebeamer 10.0
The Team field in Codebeamer trackers is used to hold references to tracker items in Team trackers. These references are used automatically to determine the visibility of the item.
To check access permissions, Codebeamer uses the assignedTo (Team members) field of the referred item. You can access the Configuration window by clicking 
and
andFor example:
Task tracker - view if owner permission for Developer role.
A user who is a member of the Developer role can see the items in the Task tracker through assignedTo and team fields if:
• The user was set to assignedTo field directly.
• The Developer role was set to assignedTo field.
• The group was set to assignedTo field, and the user is a member of the group, and the group is a member of the Developer role.
• The team was set to the Team field and the user is member of Team directly or indirectly and the user is member of the Developer role directly or indirectly.
The item with configurations as shown in the following image is not visible for test user :
The item is visible after the team assignment, as shown in the next figure:
Visibility Control for Fields and Items Using the Team Assignment Context
To manage the team members’ permissions in Codebeamer, team members must be added to a participant field on the work item.
This can be done either manually or through a expression:
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 the participant fields or roles.
Team
An upstream reference to the Software Task through the Team attribute (property name: teams):
For example, there are two teams, Team A and Team B, each team has two team members:
Follow these steps to include the required team members into the Members field on the work item, so you can manage the team members permissions.
1. Create a new Team Member field.
Any default Member type field could be used for this purpose, considering that the calculated fields are not directly editable on the work item.
2. Enable the permission configuration through the new member field.
3. Configure the auto-populate for the Team Member(s) through the Team assignment.
Add the following below expression:
distinct(teams.{team|team.assignedTo.{member|member}})
Where:
teams–The team field’s property name in the Task tracker.
team–The team tracker’s key.
assignedTo–The property name of the attribute where we assign the team members to teams.
Click OK to save the configuration.
4. Verify that the process works, and Team Member(s) field is autopopulated correctly.
When you make a new team assignment on a Software Task, team members are automatically added to the Software Task’s Team Member(s) field as shown in the next figure:
