Data access control

Set up data access control 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, automated tests, and their derived entities.

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, follow these high-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 their 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 only sees 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 is 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. Open the Settings menu and click Spaces.

  2. In the side pane, select the shared space.

  3. Go to the Permissions tab.

  4. In the main pane, select the Data Access category.

  5. In the toolbar, click the Manage Data Access button.
  6. Add new categories or rename existing ones.

Back to top

Apply data access control to a role

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 a role:

  1. Open the Settings menu and click Spaces.

  2. In the side pane, select the shared space.

  3. Go to the Permissions tab.

  4. In the toolbar, from the Role list, select the role to which you want to apply data access control.
  5. In the main pane, select the Data Access category.
  6. Select the Enable data access control checkbox.
  7. Select the categories that you want to apply to the role.

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

  8. Repeat for all relevant roles.

Back to top

Create rules to assign data access categories

You can 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 relevant role.

Different types of rules are used for different entities.

Entity Rule type Details
Defects, manual tests, requirements Business rule

For details on creating business rules, see Design business rules.

For an example of a business rule that assigns data access categories, see Assign data access categories.

Automated tests and their derived entities Test assignment rule For details, see Test assignment rules.

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 must 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 Customize fields button and add the Data access categories field.

  • To update multiple items, use bulk update. For details, see Update 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, all trend-based graphs are displayed 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. Open the Settings menu and click Spaces.

  2. In the side pane, select the shared space.

  3. Go to the Permissions tab.

  4. In the toolbar, select the role from the Role list.

  5. In the main pane, select General System Actions.

  6. Clear the View Status Over Time Graphs checkbox.

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

  3. Create a business rule that sets the Data access categories field value to Default when an entity is created. Make this rule unconditional, so that all items are updated. For details, see Design business rules.

    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 other rules that assign the specific data access categories.

Back to top

Data access control in requirements

The following guidelines apply to data access control for requirements:

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

    The data access categories assigned to a requirement's parents are indicated in the requirement's field Required data access. This field is read-only.

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

    Data access category cat1 has the suffix Parent access category.

    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-severity defects, the results include 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, a warning is displayed.

  • When running a test that includes a called test with data access categories that fall outside the tester's permissions, a step is not created 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, the tests that cannot be assigned to the default user are listed. Default users can only see the tests that they can have permission to run.

Back to top

See also: