This article describes how access rights are inherited across Blocks in an Application - also known as access rights inheritance. It also explains how to identify and how to troubleshoot access rights.
Before you begin
We recommend that you read and understand the following topics - they cover the essential basics for understanding access rights before you start working with access rights inheritance:
- Pigment Access Basics
- About Roles, Permissions, and Access Rights
- Introduction to Access Rights
- About Access Rights Metrics and Rules
What is access rights inheritance?
Access rights rules define the specific data users can view and edit.
But what happens when access rights data is referenced in a formula?
This is where we introduce access rights inheritance. When a formula references another Block, any access rights settings on the referenced Block are applied to the current Metric.
For example, let’s say a Metric references employee data. In this situation, any access rights rules for employee data apply to that Metric. If a Member doesn’t have read access to the employee data, they won’t have access to the output of the formula. The Member can see the Metric, however they can’t see the data contained in that Metric.
Using Block settings to identify access rights
When you open the Block settings for a Metric or List, the Access Rights section lists all the read and write access rules applied to a Block. This includes all inherited access rights, as well as all the Dimensions that apply access rights. These settings are unavailable for Tables because each Metric contains its own individual access rights.
There are three sections in the Access rights settings where you work with access rights inheritance:
- Access per Member
- Block configuration
- Inheriting access rights from
Access per Member
You need to have the Define Application Security permission to have access to View detailed access per Member.
- Click View detailed access per Member.
- Switch between Read Access and Write Access to view read and write access for every Member for that particular Block.
- Review the Block access rights rules section.
This displays the rules that apply directly to this Metric through an access rights rule. It also indicates if there is access rights inheritance through the use of a formula. - Toggle between the Members’ read access and Members’ write access rules section.
This displays all Members that have been added to the Application and their respective access. If an access rights rule is applied to a Dimension, you can use the Page Selector to select the values of that Dimension. - Use the following to adjust how you view your data:
- Pivot. Use this to adjust how your data is displayed.
- Show only. Toggle on and off to display only Members with only read or only write access.
Block configuration
Depending on your configuration, two settings are listed in this section:
- Data visibility management. This only applies to read access rules. You can set a Block to either Based on rules or Public.
- Public. This overrides all read access rules, allowing all Members in the Pigment Workspace to view the data.
- Based on rules. When this option is selected, the Access rights rules section is available.
- Access rights rules. When you select Based on Rules in Data visibility management, this setting is available. This lists any access rights rules applied to the Block. It typically includes the User roles rule, and can include any other additional rules based on dimensionality or specific Metric references.
Inheriting access rights from
This section displays the following:
- All Blocks that are referenced through formulas with access right settings.
- All Blocks that are referenced by the User roles access rights rule.
This is because the User roles access right rule contains an Application-wide access rights setting.
When a Block is mentioned in this section, it doesn’t mean there is necessarily a difference in access rights. If one Metric is referenced from another Metric, even if they have the same access rights, you will see that Metric listed.
There are two exceptions to when you won’t see a Block listed:
- Public Blocks. Metrics that reference Blocks marked as Public under Data visibility management do not inherit access rights. This setting overrides all access rights rules related to read access and allows every user in your Pigment Workspace to read the data.
- RESETACCESSRIGHTS Function. This function removes inherited access rights from a specific Block. It allows you select the Blocks where you want to disable access rights inheritance. When using this function, it’s important to target the appropriate expressions. Rather than applying the RESETACCESSRIGHTS function to the entire formula, focus only on the specific expression where you want to stop access rights inheritance. Being specific with where you apply this function ensures that it works as intended without affecting other parts of your formula.
Use the dependency diagram to view individual access rights
The dependency diagram provides a clear overview of how data flows through the Application, helping you identify all referenced Blocks at a glance. Members with the Define Application Security permission can enable Show Access Rights mode. When activated, this mode highlights Metrics and Transaction Lists in different colors, reflecting the selected Member's access rights settings.
The following table describes the color indicators and corresponding permissions for the dependency diagram.
Color Indicator | Permission | Description |
---|---|---|
Green | Full access | The Member has access all data within the Metric. |
Yellow | Partial access | The Member has access to only some data within the Metric. |
Red | No access | The Member has no access to data in this Metric. |
When you enable Show Access Mode, you can toggle between Members using the Members dropdown, allowing you to review each Member’s access. It’s worth noting, the dependency diagram doesn’t illustrate the same level detail as the the Impersonate setting. However, it’s an excellent way to identify access rights issues with needing a Security Admin account type.
For more information on the Impersonate setting, see Review Access Rights Configurations with Impersonate.