Understanding licenses, permissions, and access control

Server administrators and project administrators can control access to project area artifacts through the use of client access licenses (CALs), repository group permissions, team areas, roles and role-based permissions, and access control settings.

Table 1 lists and describes the mechanisms that you use to control who has access to artifacts in project areas and team areas and what actions they can perform on those artifacts. Server administrators are responsible for creating users and assigning licenses and repository group permissions to users. Project administrators and team leaders are responsible for controlling access within project areas and team areas.

Table 1. Mechanisms for controlling access to project area artifacts
Control mechanism Location Description
Client Access License (CAL) User profile CAL assignments determine the set of capabilities that users have access to across the IBM® Engineering Lifecycle Management (ELM) products. You assign CALs to users when you create users.
Repository group permissions User profile Repository group permissions assignments determine the level of access that users have to the repository. You assign repository group permissions to users when you create users.
Access control settings Project area Within a project area, you can configure the Access Control settings to determine who has read access to the project area and its artifacts.
Project area and team area membership and role assignments Project area, team area Within project areas and team areas, you add users as members, and you assign roles to those members. Depending on the access control settings in a project area, membership in that project area or one of its team areas can determine whether a user has access to project area and team artifacts.
Role-based permissions Project area, team area, timeline, iteration, iteration type After you add users as members of a project area or team area, you assign roles to those members. A member’s role, or roles, determines which actions the member can perform within the project area or team area. You assign permissions for performing actions to roles. Role-based permissions that are set at the project area level apply to all child team areas. However, within a team area, you can customize those settings. You can also specify different permission settings for specific timelines, iterations, and iteration types.
Note: A user who is assigned to a role in a project area has the permissions associated with that role in the project area and in its child team areas, even if the user is not a member of those child areas. For example, a user who has the Team Member role for a project area has the permissions associated with the Team Member role in all child team areas of that project area.
Administrator assignment Project area, team area Within project areas and team areas, you can assign users to be Administrators. Administrators have permission to save all changes to the project area or team area that they administer. Administrators typically modify aspects of the project area or team area process, such as membership and role assignments.
Fine-grained access control Project area, team area In requirements management project areas, you can restrict access to folders to members of a team area.

In change and configuration management project areas, you can restrict access to work items and source control artifacts. You can define access groups, which can consist of members of project areas, team areas, and other specific users. You can then limit access to work items to members of those access groups.

Table 2 provides an example set of users and the repository permissions and CALs assigned to them.

User 1 has JazzAdmins repository permissions and is responsible for creating users and administering the server. You can use an LDAP registry to add users to the repository.

User 2 has JazzProjectAdmins repository permissions and is responsible for creating project areas.

Within each project area, one user is the administrator and can add members, assign roles to those members, and create team areas. The change and configuration management project area, named Development project area, includes two team areas. Each of those team areas includes an administrator who can add members to the team area and assign roles to those members.

Table 2. Sample user assignments for repository permissions, CALs, and project area and team area membership and roles
Controlled by server administrator Controlled by project administrator or team lead  
User Repository permissions CAL Project area membership / Role Team area membership within project area / Role Administrator of project area or team area Description
User 1 JazzAdmins
  • IBM Engineering Test Management– Quality Professional
  • IBM Engineering Requirements Management DOORS® Next – Analyst
  • IBM Engineering Workflow Management – Developer
None None No User has complete read and write access to the repository, but is primarily responsible for creating users, administering the server, administering the data warehouse, and managing licenses.
User 2 JazzProjectAdmins
  • IBM Engineering Test Management – Quality Professional
  • IBM Engineering Requirements Management DOORS Next – Analyst
  • IBM Engineering Workflow Management – Developer
None None No User can create and modify artifacts in each of the ELM applications, but is primarily responsible for creating and modifying project areas and process templates.
User 3 JazzUsers IBM Engineering Workflow Management – Developer Development project area / Product owner (Scrum process) None Administrator of project area User can create and modify artifacts in the change and configuration management application, and is responsible for administering a specific CCM project area.
User 4 JazzUsers IBM Engineering Workflow Management – Developer None Web UI team area / Scrum master Administrator of team area User can create and modify artifacts in the change and configuration management application, and is responsible for administering the Web UI team area.
User 5 JazzUsers IBM Engineering Workflow Management – Developer None Web UI team area / Team Member No User creates and modifies artifacts that are owned by the Web UI team area.
User 6 JazzUsers IBM Engineering Workflow Management – Developer None Core team area / Scrum master Administrator of team area User can create and modify artifacts in the change and configuration management application, and is responsible for administering the Core team area.
User 7 JazzUsers IBM Engineering Workflow Management – Developer None Core team area / Team Member No User creates and modifies artifacts that are owned by the Core team area.
User 8 JazzUsers IBM Engineering Test Management – Quality Professional Test project area / Test Team Member (Quality Management Default Process ) None Administrator of project area User can create and modify artifacts in the quality management application, and is responsible for administering a specific QM project area.
User 9 JazzUsers IBM Engineering Test Management – Quality Professional Test project area / Test Team Member None No User creates and modifies artifacts that are owned by the Test project area.
User 10 JazzUsers IBM Engineering Requirements Management DOORS Next – Analyst Requirements project area / Author ( Requirements Server Template process) None Administrator of project area User can create and modify artifacts in the requirements management application, and is responsible for administering a specific RM project area.
User 11 JazzUsers IBM Engineering Requirements Management DOORS Next – Analyst Requirements project area / Commenter None No User reviews requirements, sketches, and diagrams, and provides comments.

video icon Video

Jazz.net channel
Software Education channel

learn icon Courses

IoT Academy
Skills Gateway

ask icon Community

Jazz.net
Jazz.net forums
Jazz.net library

support icon Support

IBM Support Community
Deployment wiki