When a formula references another block, any Access Rights settings on that block will be applied to the current Metric. This is called inheritance of access rights. This article discusses the different Application level Inheritance options .
Table of Contents
Before removing Access rights inheritance, please read carefully. This application level security setting could reveal sensitive data. For more information on inheritance and how to remove at the individual Metric level, please review this article.
Permissions
To remove any Access rights inheritance at the Application level, a Member must have an account type of Security Admin or higher.
They must also have Display Application and Define Application security permissions for the Application they are applying this setting to.
What is Access rights Inheritance?
Inheriting access rights means that when a formula references another block, any Access Rights settings on that block will be applied to the current metric. This ensures that data security is maintained even when data is used in different formulas or Metrics.
For example, if a Metric references Employee data any Access rights rules for Employee data would apply to that metric. If a Member 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.
For more detail on what causes Inheritance or how to identify where the inheritance is coming from, please check out this detailed article on Inheritance of Access Rights.
If you do not want the the Access rights inherited, you can use the RESETACCESSRIGHTS() at the individual Metric level. This article will discuss the Application level settings.
What are the Application level Inheritance options ?
There are two options under Inheritance options, the first is related to Shared blocks from using Libraries, the second is aimed at inheritance from within the Application. You must have the first option toggled on, in order to see the second.
Allowing RESETACCESSRIGHTS to be used on Shared Blocks
When a block is shared across application, it will maintain its access rights inheritance.
The “Allow the removal of inherited access rights for Blocks coming from other Applications using the function RESETACCESSRIGHTS()” when toggled ON allows the RESETACCESSRIGHTS() to be applied to blocks coming from other Applications. This does not remove the inheritance, it just allows for that function to be used in formulas that are referencing blocks from other applications.
This option must be toggled on the “Remove access rights inheritance through formulas within this Application.” to appear.
Removing inheritance throughout the entire Application
The “Remove access rights inherited through formulas within this Application” will remove the need for the RESETACCESSRIGHTS() function for the entire Application. Once toggled on, formulas that reference blocks within this application and shared blocks will no longer inherit access rights.
How to Activate Application level Access rights inheritance options?
There is a two step process to remove inheritance within the Application. First you must allow the removal of inherited access rights across shared block or blocks coming from other Applications. This must be enabled before the option will appear.
Steps to enable this feature:
- Within the Application, open the side panel and click on Settings.
- Click the Roles, permissions & access option.
- Navigate to the Data access rights tab.
- Towards the bottom of the page, locate the Inheritance options.
- Toggle “Allow the removal of inherited access rights for Blocks coming from other Applications using the function RESETACCESSRIGHTS()” on. Once toggled on the next option will appear.
- Toggle on “Remove access rights inherited through formulas within this Application”
Formula Playground and Drill down with Configure Blocks permission
There is some differences to note with the behavior of Access Rights Inheritance depending if the Member has Configure Blocks permission or not.
If a Member does not have Configure Blocks permission in the Application but they have Formula Playground permission, inherited access rights will still apply for the formula playground. For example, if there is a Transaction list with an access rights rule applied to it, the formula playground will still inherit the access rights that list. Thus, any formulas referencing that list will reflect the same data as configured via access rights.
The same behavior applies when a Member without Configure Blocks permission uses Drill down, drill down by, and Drill to data source on a block. Any intermediary calculations with formulas applied on blocks where there are access rights, will still have the inherited access rights rules applied from those blocks as to not unintentionally expose sensitive data.
Considerations when removing Inheritance with RESETACCESSRIGHTS() vs Application-wide option
There are some considerations when deciding which option to use to remove inheritance:
| Considerations | RESETACCESSRIGHTS() | Application-level Remove Access Rights Inheritance Option |
|---|---|---|
| Granularity of Access Rights management | Inheritance of access rights can be removed selectively on blocks when needed using the function. This allows for more granular and selective usage of inheritance when needed. | Inheritance of access rights will be removed on all blocks within the application when the setting is enabled. Data access rights has to be managed by setting up rules for every block within the application. |
| Data Access on Shared blocks from Libraries | Removal of inheritance for blocks coming from other applications is only possible if the option to remove it is enabled. Only Security Admins have the capability to do this. | The option to remove inheritance coming from shared blocks is a pre-requisite to enable the application-wide inheritance removal option, so inheritance will be removed on blocks coming from other applications as well. |
| Permissions setup for application members | Members need the “Define Application Security” permission in order to use the RESETACCESSRIGHTS() formula and remove inheritance to allow access to data in blocks within the application. | All Members will be able to read data depending on their access rights setup, with inheritance removed. Members with “Configure Blocks” permission will be able to create a new block or use formula playground and use formulas to read data from blocks where there are no direct access rights rules set on them, so make sure to use dynamic rules when relevant. For Members without “Configure Blocks” permission, access rights inheritance will still apply for Formula Playground and Drill down/by features. |
Best practices for setting up Access Rights rules when inheritance is removed with the application-wide option
Here are a few best practices to take note of when setting up Access Rights when inheritance is removed within your application:
- Use a dynamic rules when assigning an access rights rule on metrics: When inheritance is removed within the application, members with Configure Blocks permission can access data from metrics with access rights defined using the “Specific Metrics” rule, even if there has been a specific Access Rights rule preventing them from accessing the data on those metrics. This is because a user with Configure Blocks permission can either access Formula Playground or by creating a new metric, and writing a formula in it to access the data from the metric, as inheritance is removed.
- In order to avoid the risk of unintended data access for these members described above, we advise setting up your Access Rights Rules for metrics using the “All Metrics using specific Dimension(s)” option. This will ensure that members will not be able to access data on those Metrics, even through creating a new block or using formula playground.
-
- Set up access rights for shared blocks from other applications: If you have used Libraries to use blocks shared from other applications, make sure you have set up the access rights rules accordingly for those blocks.
- Grant the Configure Blocks permission with care: Because there is a risk for members with Configure Blocks permission to access data in metrics where there is no dynamic access rights rule set on it, make sure that the permission is granted only to members that need it, and that the access rights are set up dynamically on all blocks (including shared blocks) to restrict access to these members where needed.
- RESETACCESSRIGHTS() might still be required for members without Configure Blocks permission: If there is a need for members without Configure Blocks permission to access data using Drill Down / Drill down by / Drill to data source (e.g. for blocks that are on boards), there may be a need to use the RESETACCESSRIGHTS() function for those blocks. This is because inheritance may still apply in these cases for members without Configure Blocks, even when the setting to remove it has been enabled.
- Testing: Always test your access rights set up with another member or using the Impersonate feature before inviting more members to your application.