ALM: User Guide

The main purpose of Roles is to separate access to different parts of project information. For each Role you can configure access to particular project artifacts. When inviting Participants into a project, you assign Roles to them. Users receive access to the project within the permissions of the Roles assigned to them.

The system has several predefined Roles:

• Project coordinator — a project Role that can change any settings and can perform any operations in the project by default;
• Visitor — a project Role that can only read data;
• Developer, Analyst, Tester, and so on — project Roles that can perform any actions in the project, but cannot invite Participants or change the project Settings;
• Product owner — a project Role with minimal rights to change data inside the project.

One project Participant can have several Roles. In this case a granting right overrides a denying right.

There are several synthetic Roles that cannot be changed or deleted:

• All users — the access setting of this Role lets you grant access to a project (or its artifacts) to any registered users of the system, even if they are not Participants.
• Participants of linked projects — lets you configure access to artifacts of a program or of subprojects. For example, program Participants can be given access to subproject artifacts.

Access rights are granted on entities, their attributes, modules, and reports. Access rights on entities by default also determine access to the modules and reports where objects of that entity are displayed.

A user is given the Role "All users" if they are not a project Participant. For example, a user can be granted access to the "All projects" Portfolio. Such a user can open any project without being a Participant of it (with some project Role). Access rights for such a user are determined by the Role "All users".

A user is given the Role "Linked project Participant" if they open a program or a subproject without being a Participant of the program or subproject. This Role simplifies access to the data of linked projects. In some cases, however, this may be unacceptable. Then you need to configure access rights for this Role in the program or subproject. For example, to restrict subproject Participants' access to the program, deny access to the "Project" entity for the Role "Participants of linked projects" in the program's access rights settings.

Access for everyone to one project

To give all users of the system access to one project without including them in it as Participants (there may be many users), grant the Role "All users" the "View" right for the "Project" entity. After that, any user of the system can enter the project. To allow adding an Issue, creating a Task, or replying to a comment, grant the corresponding rights.