Inheritance of Access Rights and how to use RESETACCESSRIGHTS

  • 8 August 2022
  • 0 replies

Userlevel 5
Badge +5
  • Community Manager
  • 160 replies

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.


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 





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. 




When using the function, you want to be as specific as possible in the expression you include in the brackets.  




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.



This would stop the inheritance of Access Rights from only Metric A.


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


0 replies

Be the first to reply!