Assign 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.

Permission categories

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

  • 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.

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.
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.

Release Management Permissions for working with releases, sprints, and milestones.
Teams Permissions for working with teams.
Pipelines

Permissions for working with pipelines and pipeline builds.

Included in this category are permissions for running pipelines.

Administration

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

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

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

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.

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.

Admins can customize most predefined roles.

The site admin role and the space admin role cannot be customized. For details, see Edit permissions.

Admins can assign one or more of the following predefined roles to users:

  • Site admin (on-premises)

  • Space admin

  • Workspace admin*

  • DevOps admin*

  • Leader*

  • Team member*

  • Tester*

  • Viewer*

  • Synchronizer admin

* Space admins can customize the permissions for this role.

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.

  1. In Settings > Spaces, select a 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.

Back to top

Create roles

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

  1. In Settings > Spaces, select a 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 undo all changes and reset the permissions back to the original, pre-defined defaults, click Reset Role .

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:

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

Back to top

Delete user-defined roles

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

  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: