Understanding Access Rights

This article highlights  the high-level steps and options on how to apply a basic setup of Access Rights. This will be a manual set up but we also have articles on How to Set up Access Rights Using Formulas and Inheritance of Access Rights and how to use RESETACCESSRIGHTS for more advanced Access Rights configurations.

Table of Contents 

This article is based on the current Access Rights system. You can identify which system you are on by navigating to Roles, permissions & access section and seeing if you see Version: Legacy or if there is an Unspecified option for read or write permissions within a Role then you are on the Legacy system. For more information, check out this article.

 

Let’s start with what exactly are Access Rights. Access Rights are a form of data security that allows you to configure what data individual users can see and interact with. This is different from Permissions, Permissions define the actions a user can take, such as Creating new Metrics, Boards, and Lists.

For example, Permissions would define if a Member could create a new Board or write different formulas, whereas, Access Rights would establish if a user could read or write data for a specific country or department on a Board. Access Rights are strictly related to data and how users can interact with that data. 

Access Right states

When setting up Access rights, you have three states. Users either have No Access, Partial, or Full Access to data. 

• No Access – This means a user cannot see the data. 
• Partial Access – The user will be able to read some of the data but not all of it. Depending on their configuration, they may be able to Write on that data. 
• Full Access– This allows users to read all of the data. Depending on their configuration, they may be able to Write on that data as well. 

Access Rights are applied to individual Members and can be set at different levels of granularity within an Application depending on your security needs. This allows you to define exactly which data should be readable, writeable, or hidden for each individual user. Access Rights start at the highest level with Roles.

Access Rights within Roles

Roles are comprised of Permissions and Access Rights. The Access Rights defined within Roles will be considered the default setting when no other rules are applied. For example, if a Member is set to Read/ Write, they will be able to edit or write for all data where there are no other rules applied.  However in most cases, there will be a need for a more granular setting on which data users should be able to see, read or edit. This is done by creating Access Right rules through Metrics.

When applying Access Rights in multiple Metrics, the most restrictive setting will always override the least restrictive settings. For example, if a Member has the Reader role, which is set to No Write.

They will not be able to edit data if another Access right rule is set to Write. When there are multiple rules applied to the same part of an Application, the most restrictive option will always prevail. However, there is a way to establish that an Access Right rule "Does not Apply" to certain areas.

Establishing a Security Plan

The first step is to define your data security needs. This means establishing a plan for which data must be hidden, readable, or, writable and for which users this needs to apply. For this article, we are going to focus on a simple example. In reality, your security needs will be more complex. Having a defined plan from the start will make setting Access Rights much easier.

Setting up Access Rights 

Permissions needed

To be able to configure Access Rights, you must have the Define Application security Permission. This Permission is specific to each Application. If you are using the default Roles set up in Pigment, Admins have this permission applied to them. From within an application, if you see a Security Folder in the Sidebar, or able to see the “Roles, permissions & access” tab in your Application Settings, you have the correct permissions.

How does Access Rights setup work?

Access Rights are established through the creation of rules. The Rules are made by using Metrics with a data type of Access Rights dimensionalized by the User List and any dimension list on which you want to restrict data. For example, if you wanted to give users access to different Country data, we would need to ensure our Metric has the User List and Country dimension list. Once the Metric is completed, you must then go into the Data access rights settings and assign that metric as a rule.    

Rules can be set to impact Read & Write access combined or either Read or Write individual. 

When creating the rule you must define which blocks in your application that the rule is applied to or not applied to.  You can select Specific Metrics, All Metrics using specific Dimensions, Specific List Properties or List Item Values..

Creating an Access Rights Metric

An Access Rights Metric is a Metric created to define how users can interact with data. The number of Access Rights Metrics you will need to create will be dependent on your security needs. These Metrics must be set to the data type of Access Rights. They are dimensionalized by the Users list as well as the dimensional list that you want to apply data security. For example, if you wanted to restrict users to be able to only see data for particular Products, you would add the Products dimension list as well as the User list. This article will focus on an Access Rights Metric that has manual inputs and one dimension. In most instances, you will have multiple Metrics needed and will use ACCESSRIGHTS and other functions to make a more scalable approach.

When creating an Access Rights Metric, the following conditions are necessary;

• Data type - Set to Access Rights
• User list must be present to have different settings for different users
• Dimension List to which security is to be applied to, must be included

Access Right Data Type

When you set a Metric to the Access Rights data type you’ll see two different options for both the read and write settings. 

Read/Write - These will allow users to read or write data.   No Read/ No Write - This will deny a user the ability to read or write.    To make data hidden from a user, you would set it to No Read / No Write.  To give a user access to just read, you would set it to Read/ No Write and to make it writable, you would set to Read and Write.

It is important to note that when working with Access rights and Permissions if you have multiple Metrics that reference the same dimension and user combination, the most restrictive permission will always override the lesser restrictive.  

For example, let's say we have a user whose role is set to Reader, they have an application-wide Access right rule set to Read, No Write.   If you create and apply another Access Right rule that gives them Write permissions, the Application wide No Write permission will override that.  

Then, you can create two Access rights rules for the block(s) containing data you wish to be readable or writable. You can set up one rule to remove the User Role from applying to those blocks and then another rule to apply your custom Access rights settings.

The next section describes in more detail how to do this with the Applies to and Doesn't apply to settings. You can also refer to this article to learn more about setting up custom access rights [link to other article].

This example shows an Access rights metric for Countries. It is dimensionalized by Country and the User List. After creating a Metric, the next step is to apply it as an Access Rights rule. 

Understanding Applies to and Doesn’t Apply to

The Access rights configuration within the User Roles is applied to the entire application by default.  However, when creating new rules, you need to define the scope of the rule. It's important to note, there are two options, you can either select Applies to or Does not apply to. 

Applies to is used to define which parts of the application this rule is enforced.

If you select Does not apply to, you can actually limit the scope of an existing rule. 

For example, you could set up an Access right rule that Applies to every Metric that contains the Employee dimension.  However, you might have a few specific Metrics that you do not want this rule to apply to.  In this case, you would create a second rule and set it to Does not apply to and then choose the specific Metrics. 

After deciding if the rule will be used to apply or remove Access rights you have to define the area it applies to.  These are the options that are used to protect data primarily in Metrics and others aimed at Lists. Specific Metrics and All Metrics using specific Dimension(s), will protect your data within Metrics, while Specific List Properties and List item values are aimed at protecting List data.  

Specific Metric(s) 

This allows you to select one or more Metrics that contain the Dimensions used in your access rights Metric. 

If you created an access rights Metric that used the User list and the Country list, you could select Specific Metric(s) that contained the Country list.  

All Metrics using specific Dimension(s)

This will apply to all present and future Metrics that contain Dimensions used in your Access rights Metric. 

For example, if your access rights Metric contained Department, this option would then apply that configuration to all Metrics that contained Department.

Specific List Properties

Pigment lets you define on which Lists and on which Properties of this List these access rights should apply to. For example, specific Access rights for the Annual Salary property of my Employee list.

List Item Values

This rule will filter out values in the List according to the Metric of Access rights. It allows you to protect data in Lists, based on Properties.  

For example, you can set read access on Annual Salary property based on a dimension formatted Country Property.  This would allow certain Members to view some Salaries depending on the Country Property.  

Assigning an Access rights Metric

After creating an Access right’s Metric, you must apply it as a rule in Roles, permissions & access.  

1. From the sidebar, click on the Settings Icon.
2. Next, click on Roles, permissions & access.
3. Click on the Data access rights tab at the top
4. Under Rules, click the  + Add an access rights rule button.
5. Select the Rule type, should this metric apply Read, Write, or Read & Write Access to Members. 
   1. Note: For example, if you select only Read access for Rule type, Pigment will ignore the Write  part in your Metric, regardless of how it is set up in the metric.
6. Use the Applies to or Does not apply to   toggle to determine if the rule is used to apply the Metrics configuration to data or remove the Metrics configuration from data.
7. Select the area within the Application that will use this rule.

• Specific Metric(s) that already contain the Dimensions used in your Access Rights Metric. This option will allow you to choose the specific Metrics.
• All Metrics using specific Dimension(s) including the Dimensions used in your Access Rights Metric
• Specific List Properties. Pigment lets you define on which Lists and on which Properties of this List these access rights should apply to.
• List Item Values This rule will filter out values in the List according to the Metric of access rights

Multiple rules on the same dimension

When there are multiple Access rights rules applied to a dimension, the most restrictive permission will take over. The most restrictive permission is No Read / No Write. 

It is important to note that by default most user roles, except Reader, come with Read / Write permissions associated with the entire Application. When applying Access Rights rules, this needs to be taken into account.

When applying Access rights in multiple Metrics, the most restrictive setting will always override the least restrictive settings. For example, if a user has the Reader role, which is set to No Write. They will not be able to edit any data, even if another Access right setting is set to Write in an Access rights Metric, unless you set up a rule to say that the Users roles configuration Does not apply to the data you are referring to.