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.
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 Grouping Projects with Working Sets 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.
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.
An account is used to identify a user by name, and password. Account information contains data such as name, organization, e-mail, skill, etc.
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 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 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.
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
create the groups Developer, Tester and TechWriter (SysAdmin function)
create the roles Developer-access, Tester-access, TechWriter-access
edit the access pemissions for the roles
assign the group Developer, to the role Developer-access
assign the group Tester, to the role Tester-access
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
create a group Customers and
assign the group Customers to a Customer-access role on specific projects.
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.
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: