Data access control

Set up data access control in a space to control that data that can be accessed by each role.

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

Overview

Data access control allows you to restrict data access according to your organization's policies. For example, your organization may employ contractors that work alongside full-time employees on the same project, but may have a different security clearance. By applying data access control, you can enable some employees to view sensitive material while restricting others.

Data access control is enabled on a role-by-role basis. Roles are assigned to data access categories. The role can access only data that is assigned to the same category as the role.

Roles for which data access control is not enabled have open access to all data.

Setting up data access control involves these high-level steps:

  1. Create data access categories.

  2. Assign data access categories to roles.

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

Items blocked from a role are hidden in the system, including the following views:

  • Relations view of allowed items.

  • Item counts. For example, a widget displaying the number of defects does not include defects blocked from the logged in user.

Note: Both the site admin and space admin roles have full access to all data. Take this into account if your organization has strict regulations regarding sensitive information.

Manage data access control for roles

Only space administrators can create data access categories.

You can create up to 63 data access categories.

Note: To allow up to 126 categories, submit a support ticket or contact your site administrator. After increasing the limit, the limit cannot be decreased again.

To manage data access control:

  1. Open the global menu and select Administration > General Settings.

  2. In the spaces sidebar, select the shared space node .

  3. Go to the Permissions tab.

  4. In the vertical tabs, select the Data access categories tab.

  5. Select a role.

  6. Add the Assigned roles column to the grid.

  7. In the toolbar, click + Data access category and enter a name for the new category.

    Add more categories as necessary.

    All data access categories are listed in all the roles, regardless of the role in which they were defined.

  8. Enable data access control: By default, data access control is disabled for all roles. This means that during the process of defining data access categories, the roles have access to all data. After you enable a role's data access control, the role can access only data assigned to the same categories as the role.

    If you enable data access control but do not activate any category, data access is completely blocked for that role.

    After a role's data access control is enabled, you can activate categories for the role.

    Note: Categories may be assigned to a role in the categories grid of another role. Even so, the categories remain deactivated for the current role while the role's data access control is disabled.

  9. By default, a new category is not assigned to any role.

    • To assign a category to the current role, click the role's Active button, or click Activate in the toolbar.

    • To assign a category to other roles, click inside the category's Assigned roles field, and select roles.

    • The Assigned roles field displays all roles to which the access category is assigned, regardless of the currently selected role.

Define a default category

Ideally, all items should be assigned to one of more data access categories. This ensures that items are accessible only by roles that are assigned the appropriate categories. However, there may be cases where an item is not assigned to any data access category, in which case it is blocked from all roles that have data access control enabled. To avoid such cases, you can define a default category and assign it to items automatically via a general business rule.

To define a default category:

  1. Create a Default category in the list of data access categories.

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

  3. Apply the Default category to all roles. For details, see Manage data access control for roles.

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.

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.

Exclude trend graphs for a specific role

Trend-based or status over time graphs display historical information. Because data access can change over 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 global menu and select Administration > General Settings.

  2. In the spaces sidebar, select the shared space node .

  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.

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.

Notes and limitations

This section lists the data access control limitations.

General

  • Data access categories cannot be deleted.

  • Cross-filter results are based on the entire data set and ignore data access categories. For example, if a tests grid is filtered by tests associated with high-severity defects, the grid includes also tests that are associated with defects that are inaccessible to the user.

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

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

See also