ALM User's Guide

Main purpose of roles is to isolate access to different parts of project information. You can set up access to the particular project artifacts for each role. When you invite participants into the project, you assign roles to them. Users get access to project within boundaries of the permissions assigned to them.

There are several predefined roles in the system:

• Project manager - by default, this project role can change any settings and perform any operations in a project;
• Visitor - this project role can only read data;
• Developer, Analyst, Tester, etc. - project roles which can perform any actions in a project, but cannot invite participants and change project settings;
• Product owner - this project role has minimal permissions to change data within a project.

A project member can have several project roles. In this case, the allowing permission overwrites the prohibiting permission.

There are several synthetic roles that cannot be changed or removed:

• All users - this role allows to grant access to a project (or its artifacts) to any registered system users, even if they are not members of this project.
• Linked project participants - this role allows to set up access to the artifacts of program or sub-projects. For example, you can set up access to the subproject artifacts for program members.

Permissions are granted for entities, their attributes, modules, and reports. By default, entity permissions also allow access to modules and reports where objects of this entity are displayed.

The role "All users” is assigned to a user if he is not a project member. For example, you can grant user access to portfolio "All projects". Such user can open any project, though he is not a project member (he does not have any project role). Permissions for such user are defined by role "All users".

The role "Linked project participants” is assigned to a user if he enters a program or a subproject without being this program's or subproject's participant. Such role simplifies access to data of linked projects. However, it can be unacceptable in some cases. Then you must set up permissions of the role in the program or in the sub-project. For example, if you need to restrict access to the program for the sub-project’s participants, prohibit access to entity "Project" in the program permission settings for role "Linked project participants".

Access to one project for all users

To grant all system users access to one project without including them into it as participants (there can be many users in the system), grant permission "View" for "Project” entity to role "All users". Now any system user can open this project, add an issue, create a task, or reply to a comment.