Roles and permissions

A role and its permissions determine what actions a user may perform and what areas of ALM Octane they can view.

Overview

ALM Octane employs role-based access control (RBAC). A user’s role is made up of permissions based on his function, like Leader or Tester. In shared spaces, the role also includes data access control.

ALM Octane includes predefined roles, most of which can be customized. For details, see Predefined roles.

Roles, permissions, and data access are defined at the space level. They are relevant for all associated workspaces. Roles cannot be modified on a workspace level.

Roles, permissions, and data access are managed by space admins.

Regardless of defined roles and permissions, space admins have full permissions to manage any workspaces they are assigned to.

Back to top

Permissions

Permissions are assigned to roles, and are organized into permission categories, such as backlog, administration, testing, and more.

To see the permissions available by role, select Settings > Spaces > Permissions, and select each role. To view this tab, the parent shared space node (for example Default Shared Space) must be selected in the left pane.

Note: ALM Octane does not support permissions to disallow views of specific entity types. Even if a user is only permitted module access to certain entities, other entities can be seen via the Relations tab. For details on how to add further permission customization, see Data access control.

Permission categories

The following table lists the permissions available for each category. These permissions control:

  • How users with the selected role can work with each item in the category.

  • In some cases, whether a user with the selected role can perform additional actions related to the category.

Tip: To learn more about a property, hover over its Help icon .

Category Description
Tests Permissions for working with all test types and also parameter tables.
Runs

Permissions for working with runs for each type of test.
Backlog

Permissions for working with work items and tasks.

Included in this category are permissions for ranking and planning.

Requirements Permissions for working with requirements and folders.
Application Modules Permissions for working with application modules.
Release Management Permissions for working with releases, sprints, and milestones.
Teams Permissions for working with teams.
Security

Permissions for working with vulnerabilities.

Note that for security purposes, ALM Octane also enables you to grant or block view access to vulnerability data.
Pipelines

Permissions for working with pipelines and pipeline builds.

Included in this category are permissions for running pipelines.

Integrations The Comment on behalf permission is for integrations only, to enable identification of comments by users when using the API key to import. This should not be used for any other purpose.
Administration

Permissions for customizing the workspace, such as customizing workflow, phases, forms, and rules.

DevOps Administration Permissions for customizing pipelines, CI servers, and collaboration tools.
General System Actions

Permissions for the actions in this category apply across all of ALM Octane and are not related to any specific functional category. For example, you can set permissions for sending email and managing environments.

This area also include permissions for the creation and manipulation of document reports. For details, see Document reports.
Module Visibility

Permissions for the actions in this category let you customize which roles have UI access to each ALM Octane module. This is for convenience, so users only see areas that are relevant to them.

Module visibility permissions do not affect the user's ability to perform actions for items in the module. For example, a user has full permissions for defects, but no permission to view the Defects module. This user can still view, update, and create defects using the REST API or from other modules, such as Backlog or Quality.

Data Access Permissions for creating and editing data access control categories and assigning them to roles.

Permissions

After choosing a role, you can assign permissions by item.

For the exact permissions you can assign, see ALM Octane Settings > Spaces > Permissions. Make sure the shared space parent node is selected in the workspaces tree.

The permissions are grouped by the following types.

Type of Permissions Description
Standard permissions Most items have the standard Create, Update, and Delete permissions available for assignment.
"By author" permissions

By author permissions are permissions that are granted only to the item's creator.

Example: 

  • Delete by author permissions for a test enables the test's designer to delete the test.

  • Delete by author" permissions for a defect enables the user who detected the defect to delete it.

  • In both these cases, the user designated in the Owner field cannot delete the test or the defect because this user did not create the item.
Category-specific permissions

Some actions are relevant to specific categories only. For example, you can set the permissions for running a pipeline for the Pipelines category only and you can set the permissions for ranking work items in the Backlog category only.

Other permissions

Some items have additional permissions, such as managing relations between items, performing certain actions, or the ability to access certain modules.

There are also permissions that include a combination of other permissions:

  • If your role is assigned the Manage Relations set of permissions, you automatically have create, edit, and delete permissions for relations.

  • If your role is allowed to create an item, you also have the ability to edit any item you create.

  • If your role is allowed to create releases, teams, administration items, and Devops items, you can also edit items created by others.

Back to top

Predefined roles

This section lists the predefined roles in ALM Octane. The predefined roles have a set of preset permissions. Admins can customize the permissions for the predefined roles. The site admin and space admin roles cannot be customized. For details, see Edit permissions.

Admins can assign users one or more of the predefined roles.

The following table lists the predefined roles and a provides a general outline of their preset permissions:

Role General permissions
DevOps admin Has similar permissions to the Leader role, plus full permissions in the Pipelines and DevOps Administration categories.
Leader In addition the Team Member permissions, can edit teams, delete items created by other users, and has full permissions in the Application Modules category.
Release Manager Has full permissions in the Release Management category. Has limited permissions in most areas of ALM Octane. For example, cannot create backlog items or tests.
Shared Entities Manager

Available in shared spaces only. Has permissions to manage shared items, such as shared epics, releases, sprints, and milestones, as well as application modules (similar to shared space admins).

Note: Shared space admins can add custom roles based on the Shared Entities Manager role. These roles will also be marked as shared .
Team Member Has create and edit permissions for items in the Tests, Runs, Backlog and Requirements categories.
Tester Has create and edit permissions for items in the Tests and Runs categories. In the Backlog category, can create and edit defects and BDD specifications.
Viewer Has only view permissions in all areas of ALM Octane. Cannot create or edit.
Workspace Admin Has full create and edit permissions in all categories. The only permission the Workspace Admin does not have by default is the permission to delete comments created by other users.

Back to top

View roles and permissions

Space admins can check which permissions have been assigned to each role for each functional category of ALM Octane.

To view roles and permissions:

  1. In Settings > Spaces, select a shared space.

  2. In the Permissions tab, select a role from the drop-down list.

  3. Click any of the functional categories. The permissions are displayed for each item.

Space admins have full permissions to edit workspace content for any workspace they are assigned to, without the permissions being explicitly granted to the space admin. When viewing the permissions for the space admin, workspace-related permissions are also displayed.

REST API: You can retrieve the permissions of each role using the REST API request: .../api/shared_spaces/<space_id>/roles?fields=actions

Back to top

Create roles

In addition to the predefined roles supplied with ALM Octane, space admins can create new roles with customized permissions.

To create a role:

  1. In Settings > Spaces, select a shared space.

  2. In the Permissions tab, click Add Role.

  3. Enter a name for the new role.

  4. Select an existing role on which to base this new role's permissions.

  5. For each item, check or clear the permissions.

  6. To rename a role, from the Role list, select the role you want to rename, click the Rename Role button, and edit the role name.

    You can rename only user-created roles.

Back to top

Edit permissions

Space admins can edit permissions for:

  • User-defined roles

  • All other roles, except for site admin and space admin

Space admins have full permissions to edit workspace content for any workspace they are assigned to. These permissions cannot be edited.

To edit permissions for a role

  1. In Settings > Spaces, select a space.

  2. In the Permissions tab, select the role from the Role list.

  3. For each item, check or clear the permissions.

Tip: To reset a role's permissions to the original, pre-defined definitions, click Reset Role .

Reset Role resets the role's permissions across all the categories, not just in the selected category.

Back to top

Assign and unassign roles

Some admins can add and remove roles for existing users. Every ALM Octane user must be assigned at least one role in each workspace to which he/she is assigned.

Roles can be assigned when:

  • Creating or editing users. For details, see Users.

  • Defining API access. For details, see API access.

You can assign roles in the workspace level and in the space level:

Assign and unassign roles at the space or workspace levels.

Workspace admins and space admins cannot unassign themselves from their roles. Other admins can do this for them.

Note: To see all of a user's roles and workspaces, click the user ID. You may also assign or unassign roles and workspaces in this view.

From the space level

  1. In Settings > Spaces, select a space.

  2. In the Users tab, click a row to select a user. Shift-click to select additional users.

  3. Click Assign to Roles/Workspaces or Unassign from Roles.

  4. Select the roles and workspaces that you want to assign or remove.

    • To add another role to the same user, click Add role to assign. You may assign roles to multiple workspaces for a single user.

    • To remove a role, click Unassign from Roles and select a role to unassign and the workspaces from which to remove the role.

      You cannot remove a user's last remaining role. Each user must be assigned to at least one role in each workspace to which he/she is assigned.

  5. Click Assign or Unassign.

From the workspace level

  1. In Settings > Spaces, select a workspace.

  2. In the Users tab, click a row to select a user. Shift-click to select additional users.

  3. Right-click and choose Bulk Update.

  4. Select the Roles field.

  5. Select the Roles to assign. If you want to unassign a role, make sure it is not selected.

  6. Decide if you want the changes to overwrite the existing roles.

    To unassign roles, you must choose Replace existing values.

  7. Click Update.

For details, see Manage the site.

Back to top

Delete user-defined roles

Space admins can delete user-defined roles that are not assigned to any users or API keys.

To delete a user-defined role:

  1. In Settings > Spaces, select a space.

  2. In the Permissions tab, select a role from the drop-down list.

  3. Click Delete Role.

If the role is assigned to any users or API keys, the role is not deleted.

Back to top

See also: