Set up data hiding in your shared space to allow users to access only the data that they are entitled to see.
- Data access control is supported for defects and manual tests.
- Data access control is also supported for requirements.
- Data access control is supported for shared spaces only.
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 means that you can do just that.
Data access control categories are created, applied to roles, and then items, in this order. A user with a certain role will only be able to see items that have one of the data access control categories included in his role.
A user with restricted data access will not be able to see any information on that item, including relations to other items. Data access also affects count. For example, a graph displaying the number of defects, will only display the number of defects that the user has access to. The user will not know that the item exists.
Note: Generally, The current access that a user has determines what the user can see. For example, if a user was granted additional access, the user will be able to see additional items along with all of their relevant history. The only exception is trend graphs, which display information regardless of data access. However, you can exclude trend graphs for certain roles. For details, see Exclude trend graphs for a specific role.
To apply data access control, you must first create data access control categories.
You can create up to 63 data access categories.
You must be a space admin.
To create data access categories:
In Settings > Spaces, select a shared space.
In the Permissions tab, from the middle pane, click Data Access, and then click Data Access Categories.
In the Data Access Categories dialog box, add the required categories.
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:
- In the Permissions tab, from the Role list, select the role to which you want to apply data access control.
- Select the Enable data access control check box.
Select the categories that you want to apply to the role.
Note: If you enable data access control but you do not select a category, data access will be completely restricted for that role.
- Repeat for all relevant roles.
By default, if data access has not been enabled on you role, full data access is granted to all items. However, if data access has been enabled on your role, you will only be able to see items that include the data access categories in your role.
To enable access to certain items, you need to assign data access categories to those items. You can do this using business rules or manually.
Create rules for assigning data access categories to items:
Create rules for assigning data access categories to items. For details, see Create a rule.
If you want to update an item both upon creation and during editing, create a separate rule for each.
Note: The When creating an entity option includes copied, duplicated, and imported items, in addition to newly created items.
The following is an example of a rule that assigns the External - restricted data access category to defects when the owner of the defect has the External Tester role.
Note: To avoid situations where items are left without a data access category, you can define a default category and assign it using a dedicated rule. Run this rule first, so that it doesn't override specific item categories. For details, see Define and assign a default category.
If you have strict regulation regarding sensitive material, keep in mind that the Admin and the Space admin both have full access to all data.
Assign data access categories to items manually
You must have the Manage Data Access permission (available from Permission > Backlog tab) to assign data access to categories.
You can only assign data access categories which you have yourself.
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 data access categories in the Data access categories field.
If this field is not displayed, click the Customized fields button, and select it.
- To update multiple items. Follow the instructions in Update multiple backlog items.
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 that graph.
You can restrict certain roles from viewing trend-based graphs on the restricted items types by clearing the View Status Over Time Graphs check box in Permissions > General System Actions.
This prevents the user from configuring or viewing trend-based graphs for the item type, regardless of the user's data access permissions.
Data access categories can be assigned to items using rules or manually. Ideally, rules would cover all use cases, but since this cannot be guaranteed, there may be cases where some items are left without a data access category, making them inaccessible to the relevant role.
To avoid situations where items are left without a data access category, you can define a default category and assign it using a dedicated rule.
To define a default category and assign it using a dedicated rule:
When you create the data access control categories, create a default category as well. For details, see Create data access control categories.
When you apply data access control to roles, in addition to the specific data access categories, apply the default category to all roles. For details, see Apply data access control to roles.
When you create rules for assigning data access categories to items, 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 Assign data access categories to items.
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.
When you use data access control for requirements, you need to be aware of how it works with the requirement hierarchy.
Data access on a lower-level item is dependent on its parent's 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 which categories have been assigned to the item's parents, so that they are relevant to the current item as well.
In the Data access categories field, categories that have been assigned to an item's parent will be given the suffix Parent access category. This indicates to you that these categories are relevant to the current (child) item. For example, if a root requirement has two categories assigned and its child has only one, the available categories in the third level of the hierarchy would look like this:
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 will be available for assignment to the child item as well.
Upgrade from 15.1.40
Important note regarding manual tests that were created before 15.1.40:
To assure that existing tests can initially still be accessed by all users, manual tests that were in the system before the 15.1.40 upgrade are assigned all the current and new data access categories.
To begin setting up data access controls for manual tests, we recommend first assigning a default category to all existing tests.
Here's a recommended procedure:
- Create an additional data access category called default.
- Assign the default category to the roles in the system that have data access control enabled.
- Filter the manual tests by items whose Data access categories field is not empty.
- Perform a bulk update on all the filtered manual tests, replacing the current data access categories values with Public.
For more details, see Define and assign a default category.
Until you update the Data access categories value of the existing manual tests, the tests will continue to be visible to all users. Until that point, new data access categories will also be assigned automatically to the tests.
Notes and limitations
This section includes data access control limitations:
Data access control 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 will 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 will be 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.
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 will issue a warning.
When running a test that includes a called test with data access categories that fall outside the tester's permissions, ALM Octane will 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 will list the tests that cannot be assigned to the default user. The default user will only see the tests that he has permissions to run.