This article discusses how Access Rights are inherited across blocks in an application, how to troubleshoot access rights and how to use the RESETACCESSRIGHT function. If you are not familiar with the basics of Access Rights, please start with this article.
Table of Contents
What does it mean to “Inherit access rights”?
In the basics, we covered how Access rights can be applied with User Roles and Access Rights Metrics converted into Access Rights Rules in the Security Panel. This is how we can define what users can see and edit. But what happens when that data is referenced in a formula? This is where the concept of inheriting access rights comes into play. When a formula references another block, any Access Rights settings on that block will be applied to the current metric. For example, if a Metric references Employee data any Access Rights rules for Employee data would apply to that metric. If a user does not have read access to the employee data, they will not have access to the output of the formula. They will be able to see the metric, just not the data within it..
Using Block Settings to identify Access Rights
Metric and List block settings contain an Access Right section, from here you can see all the Rules applied to a block, all inherited access rights, and all the dimensions applying access rights. Tables do not have this because each Metric holds its own Access Rights. At the top of the settings, you can switch between identifying Read access and Write Access.
Access per Member
Users must have the Define Application security permission to access the View detailed access per Member.
Click View detailed access per Member to be able to see the Write and Read Access for every user for a particular block. This view will show you access by member down to the individual item. In the top left, you can switch between Read and Write Access to view the different types of access.
Under Block access rights rules, you will see the rules that apply directly to this metric through an Access rights rule. Under this section, you can see if there are any inheritance of access rights through the use of a formula.
The right side of the modal contains all users that are added to the application and their respective access. If there is an access rights rule applied to a dimension, you will be able to select the values of that dimension, as well as pivot it for an easier view.
For example, if there is an access rights rule on the Country dimension, you will see this dimension as a page selector to be able to view the configuration in more detail. You can also pivot the view by clicking the Pivot button in the top right.
There is also the ability to toggle the view to only see those with Read or Write access by selecting the Show only toggle in the top right. The sort option is available to sort by users or any dimension that there is an access rights rule applied on.
Read access rights for this block / Write access rights for this block
This section at the top in the gray block shows a summary of the current access rights being applied. If they rules applied to this block are based on dimensionality, the dimensions will be listed.
Block configuration
There are two settings in this section, Data visibility management, and Access rights rules. Data visibility management only applies to Read access rules.
Data visibility management
This setting only applies to Read access rules. This will allow you to choose if you want your make a block Public or Based on rules. If you choose to make it Public, this setting will override all access rights rules related to Read access and allow every user in your Pigment workspace to read the data.
Choosing Based on rules will then show you an Access rights rules setting. This section shows any Access Right rules applied to Block. Assuming you are using the User roles rule throughout your application, you will most likely have that rule in this section. You will also see if any other rules apply to this block due to its dimensionality, or the metric being specifically mentioned in a rule.
Inheriting access rights from
This section will show you all of the blocks that are being referenced via a formula that contains Access Right settings. If you are using the User roles rule, you will most likely see all referenced blocks in this section. This is because the default User roles contain an application-wide access right setting. When a block is mentioned in this section, it does not mean there is necessarily a difference. 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.
If a block is made Public in the Data visibility management setting on a block, the metrics that reference it will not inherit any access rights. This setting is located in the Read access section of a block. You’ll see it listed as an option for Data visibility management. This setting will override all access rights rules related to Read access and allow every user in your Pigment workspace to read the data.
The second is when the RESETACCESSRIGHTS function is used. This function will remove any inherited access rights from an individual block. This function allows you to pick which blocks you do not want to inherit access rights on. It is important to be specific when choosing which expression to apply the RESETACCESSRIGHTS function to. You want to avoid using the entire formula with the RESETACCESSRIGHTS parameters, instead picking out which expression you want to stop the inheritance of access rights.
How to use the Dependency Diagram to view individual Access Rights.
The Dependency Diagram shows users how data flows through the application. This allows you to identify all the referenced blocks. Users with the Define Application security permission will have the ability to turn on Show access rights. This mode changes the colors of Metrics and Transaction lists to show a color based on a selected user's Access Rights settings.
- Green - Full Access - The user can access all data within the Metric
- Yellow - Partial Access - The user has access to some but not all data within the Metric
- Red - No Access - The user has no access to data in this Metric.
After turning on Show Access Mode, you can toggle between users using the Members dropdown, allowing you to look at each individual’s access. While it doesn’t show you the exact details as the Impersonate functionality does, it is a great way to identify what could be the root of access rights issues without needing to be a Security Admin
How to use RESETACCESSRIGHTS
This section will focus on the RESETACCESSRIGHTS function which is a targeted option for removing inheritance. There are different options you can use at application level when it comes to inheritance. Read this article for an overview.
The RESETACCESSRIGHTS function will stop Access Rights from being inherited from a block. This will not affect the access rights on that source block, it will just stop the block’s access rights from applying to the block referencing it.
Syntax
RESETACCESSRIGHTS(expression)
When using the function, you want to be as specific as possible in the expression you include in the brackets.
Examples
RESETACCESSRIGHTS(Metric A + Metric B)
This would stop the inheritance of Access Rights from both metrics. This could lead to exposing more data than you intend. You want to be as specific as possible.
RESETACCESSRIGHTS(Metric A) + Metric B
This would stop the inheritance of Access Rights from only Metric A.
Metric A + RESETACCESSRIGHTS(Metric B)
This would stop the inheritance of Access Rights from only Metric B.
You might want to maintain the access rights being inherited from either Metric A or Metric B. The following sections will show tools to use to identify which inherited access rights you wish to stop, and how access rights react to different use cases.
Cases for when to use RESETACCESSRIGHTS
In order to better understand which expressions to include within the parenthesis with the RESTACCESSRIGHTS function, it is important to understand the different cases. You want to be as specific as possible when applying the RESETACCESSRIGHTS function and avoid using it across entire formulas. By identifying the correct source of undesired inherited access rights, you can eliminate those access rights while still maintaining data security.
Aggregations
When referencing an aggregation of a dimension with an access rights rule applied to it, a user must have full access to the data in order to see the total.
For example, if an Employee Dimension has access rights applied and you reference a total for all salaries to be included in an expense line. The aggregation total will be denied to any user who does not have full access to all employees. If a user only has partial access, they will be denied access to the aggregation total. To be able to see the Total Salary Costs, you would use the RESETACCESSRIGHTS FUNCTION.
If a user does not have Full Access to a dimension, they will not be able to see the total of that dimension. It doesn’t matter if there are unpopulated or blank values in the referenced data. They must have Full Access or the RESETACCESSRIGHTS function must be used.
Shared dimensions across applications
Shared blocks maintain their Access Rights when being used by another application. The functionality to allow users to use the RESETACCESSRIGHTS function on shared blocks must be enabled in the application that wishes to stop the inheritance of the Access Rights.
In the security settings page under Inheritance options, there is a toggle to allow the removal of inherited access rights for Blocks coming from other Applications using the function RESETACCESSRIGHTS. This toggle is for Security Admin’s only and must be enabled.
Error: Function Error: the RESETACCESSRIGHTS function is not valid on this expression as it tries to remove Access Rights inherited from other applications.
This is the error you will receive if you do not have this functionality enabled.
To increase performance when multiple rules are inherited and not necessary
This use case is when an application has dimensions that are part of a hierarchy through a group property or mapping attribute with Access rights defined on multiple levels. There is potential to have multiple rules being inherited to a Metric. While this is not a problem, there are rare cases where this can cause performance issues depending on the size of lists and how many blocks are being inherited.
For example, you could have an Employee and Department list that are part of a hierarchy and have two different Access Rights rules set up for all metrics using those dimensions. Two different rules are needed to account for some metrics being dimensionalized by Employee and others dimensionalized by Department. There could also be another Access Rights rule for a County dimension. When we have a Metric, dimensionalized by Country, Employee, and Department, that references multiple blocks that also have these dimensions, it can lead to performance issues. The inherited Access Rights rules are not necessary because the Metric that is inheriting the rules will already have those rules applied due to its dimensionality. In cases like this, you can use RESETACCESSRIGHTS to eliminate the duplication of these rules.
