Understanding licenses, permissions, and access control

Edit online

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.