Data access control

Set up data hiding in your shared space to allow users to access only the data that they are entitled to see.

Note:  

  • Data access control is supported for defects, manual tests, requirements, and automated tests, and their derived entities.

  • Data access control is supported for shared spaces in Enterprise edition.

Overview

Data access is typically determined by security classifications. For example, your organization may employ contractors that work alongside full-time employees on the same project, but may have a different security clearance. You may want to enable some employees to view highly sensitive material, while restricting others. Data access control allows you to restrict the data access according to your organization's requirements.

To set up data access, you need to follow these hi-level steps:

  1. Create data access categories

  2. Assign data access categories to roles

  3. Assign data access categories to items, either via a rule or manually.

A user with a certain role can only see items that have the data access category included in his role. A user with restricted data access will not see any information on the restricted items, including their relations to other items.

Data access also affects the count property of an item. For example, a graph displaying the number of defects, displays only the number of defects that are visible to the user. The user will not know that the hidden item exists. \

By default, if data access has not been enabled for a user's role, full data access is granted to all items. If data access was enabled for the user's role, the user will only see items that include the data access categories enabled for that role. If data access has been enabled for the user, but no categories were selected, the user will be excluded from all data.

Note:  

  • For pipelines, a user with data access restrictions may still see the total number of tests in graphs and pipeline buckets.

  • Trend graphs display information regardless of data access. You can, however, exclude trend graphs for certain roles. For details, see Exclude trend graphs for a specific role.

  • If your organization has strict regulations regarding sensitive information, consider that both the Site admin and the Space admin have full access to all data.

Back to top

Create data access categories

To assign data access control, you must first create data access categories. You must be a Space admin to create the categories.

You can create up to 63 categories.

To create data access categories:

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

  2. In the Permissions tab, in the middle pane, click Data Access.

  3. Click the Manage Data Access button.
  4. Add new categories or rename existing ones. Click Save.

Back to top

Apply data access control to roles

By default, full data access is granted to all roles.

To restrict data access, you must enable data access control for each role, and select the category that you want to apply to that role.

To apply data access controls to roles:

  1. In the Permissions tab, from the Role list, select the role to which you want to apply data access control.
  2. In the left pane, select Data Access in the items list.
  3. Select the Enable data access control checkbox.
  4. Select the categories that you want to apply to the role and click the Save button.

    Note: If you enable data access control but do not select a category, data access is completely restricted for that role.

  5. Repeat for all relevant roles.

Back to top

Create rules to assign data access categories

This section describes how to create rules for assigning data access categories to items. You do this by designing a rule for the entity that you want to restrict or allow and creating a condition for the desired role.

  • For defects, manual tests, and requirements, you create a standard business rule. For details, see Design business rules.

  • For automated tests and their derived entities, you create a Test Assignment rule. For details, see Create test assignment rules.

Data access rules

The following procedure creates rules that assign data access categories to items when they're created or changed. The rules apply to requirements, defects, and manual tests. For rules for automated tests, see Add automated tests.

  1. In Settings > Spaces, select the shared space.
  2. In the space settings, select the Entities tab. In the middle pane, click on the Rules tab.
  3. Select an entity that supports data access restriction such as Defect, Manual Test, or Requirement Document.

  4. Click the Add Business Rule button , to create a new rule.

  5. In the Action tab, select Set field value as the action to perform.

  6. Select a timing option, such as When creating an entity or When changing a value. To update an item both upon creation and during editing, you need to create two separate rules.

    Note: The When creating an entity option includes copied, duplicated, and imported items, in addition to newly created items.

  7. In the Field to set dropdown, select Data access categories.

  8. In the Change options, select Set value, and click the dropdown arrow. Select the data access categories that you want to include in the rule.

  9. Add a remark that describes the rule. For example:

  10. Click the Condition tab and choose the include operator for the desired role.

To avoid situations where items are left without a data access category, define a default category and assign it using a dedicated rule. Run this rule first, so that it does not override specific item categories. For details, see Define and assign a default category.

Test Assignment rules

To create a Test Assignment rule for data access for the Automated Tests entity and its derived entities:

  1. In Settings , select Test assignment rules from the menu's Management section.

  2. Click + Assignment Rule, to create a new rule. For details, see Create test assignment rules.

  3. Click + Add filter to add conditions based on the values of the following fields: Class name, Component, Name, and Package.

  4. In the Assign area, select Data Access Categories from the dropdown. In the adjacent value dropdown, select one or more data access categories. Automated tests that match the filter will automatically be assigned the data access categories that you selected.

  5. Click Save.

For details on managing test assignment rules from the Tests tab, see Assign tests to application modules and backlog items.

Back to top

Assign data access categories to items manually

This section describes how to manually assign data access categories to items. To perform this type of assignment, you need to have the Manage Data Access permission (available from Permissions > Backlog).

You can only assign data access categories to users, if you have access to those categories. You can assign data access categories to a single item or to multiple items.

  • To update a single item: In the item's Details tab, select the relevant categories in the Data access categories field.

    If this field is not displayed, click the Customized fields button, and add the Data access categories field.

  • To update multiple items: Follow the instructions in Update multiple backlog items.

Back to top

Exclude trend graphs for a specific role

Trend-based or status over time graphs display historical information. Because data access can change from time to time, ALM Octane displays all trend-based graphs without data restrictions.

Note: Trend-based graphs only display the number of items (count). You cannot access any other information on the item from the trend graph.

You can restrict certain roles from viewing trend-based graphs on the restricted item types. This prevents the user from configuring or viewing trend-based graphs for the item type, regardless of the user's data access permissions.

To restrict a role:

  1. Navigate to PermissionsGeneral System Actions.

  2. Select the role from the Role dropdown.

  3. Clear the View Status Over Time Graphs checkbox and click Save.

Back to top

Define and assign a default category

You assign data access categories to items using rules or manually. Ideally, rules should cover all use cases, but there may be cases where an item is not assigned to any data access category. If an item is not assigned a data category, it will be inaccessible to a users with certain roles.

To avoid situations where items are not assigned a data access category, you can define a default category and assign it to items using a dedicated business rule.

To define a default category and assign it through a business rule:

  1. Create a Default category in the list of data access categories. For details, see Create data access categories.

  2. Apply the Default category to all roles, in addition to the specific data access categories. For details, see Apply data access control to roles.

  3. Create a rule for assigning the Default category to items upon creation. Make this rule unconditional so that all items are updated. For details, see Create rules to assign data access categories.

    Note: The default category is temporary and should be overriden by the specific category assigned to the item. Make sure to run this rule first, before the other rules for assigning the specific data access categories.

Back to top

Data access control in requirements

This section describes the considerations for using data access control for requirements. The following guidelines apply:

  • Data access on a lower-level item is dependent on its parents' categories. For example, if the root requirement requires category1, users without access to category1 will not see any of its descendant requirements.

  • In addition to the Data access categories field where you define the item's category, requirements have an additional field: Required data access. This is a read-only field, indicating the categories assigned to the item's parents, so that they will be relevant to the current item.

  • In the Data access categories field, categories that have been assigned to an item's parent are given the suffix Parent access category. This indicates that these categories are relevant to the current (child) item. In the following example, a root requirement has two categories assigned to it and its child has only one. The available categories in the third level of the hierarchy are shown with the suffix:

    In this example, assigning cat2 to the third-level item would be meaningless because its parent does not have cat2 assigned. If you add it to the parent, it also becomes available for assignment to the child item.

Back to top

Notes and limitations

This section lists the data access control limitations:

General

  • Data access categories can be edited but not deleted.

  • Cross-filter results are based on the entire data set and disregard your data access categories. For example, if you create a filter for returning all tests that are associated with high defects, you also get tests that are associated with defects to which you do not have access.

  • The number of test runs in a pipeline run shown in widgets are presented for all data access categories. This applies to the Test statuses by pipeline run widget and other pipeline related widgets that show test runs.

  • In multi-value fields that contain values or references to items that fall outside your data access categories, such values and references are hidden from you. If you update the fields with values or references that you have access to, the hidden values and references may be removed from the field.

    For example, if a defect's Backlog coverage field contains references to defects that belong to data access categories that you do not have access to, when you update the field with other defects, the first defects may be removed from the field.

Manual tests

  • When calling a test in a manual test step, if the called test belongs to different data access categories than the host test, ALM Octane issues a warning.

  • When running a test that includes a called test with data access categories that fall outside the tester's permissions, ALM Octane does not create a step for the called step.

  • Test suite runs: When assigning a test suite run to a default user, if the default user does not have permissions to run all the tests, ALM Octane lists the tests that cannot be assigned to the default user. Default users can only see the tests that they can have permission to run.

Back to top

See also: