This article is an introduction to access rights in Pigment. It explains the essential basic concepts and is required reading before you start implement Member access rights in Pigment.  For more information, see Define and Apply Custom Access Rights oLegacy]. 

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

So, how are access rights different to permissions?

• Permissions define the specific actions a user can do in Pigment, such as creating new Metrics, Boards, and Lists.
  For example, permissions determine if a Member can create a new Board or write different formulas. However, access rights determine if a user can 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, Members can have the following three states:

• No Access. Member cannot see the data. 
• Partial Access. Member can 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. Members can 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 security needs. This allows you to define exactly which data should be readable, writeable, or hidden for each individual Member. Access rights start at the highest level with Roles. 

Access rights within Roles

You need to define permissions and access rights when you set up a new Role in Pigment. The access rights that you define for a Role are considered to be default setting when no other rules are applied, and apply to the entire Application. 

For example, let’s say a Member’s access rights is set to Read/ Write. This Member can edit or write any data if no other rules are applied.

This is why you need to apply a more granular security setting to indicate precisely which data Members can see, read or edit. You can also establish where in Pigment an access rights rule doesn’t apply, or where it should be ignored. This is done by creating access right rules through Metrics.

When access rights are defined in multiple Metrics, the most restrictive rule prevails. For example, a Member with the Reader role set to No Write cannot edit data, even if another rule allows writing. The most restrictive setting always takes precedence when multiple rules apply to the same part of an Application.

Establish 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 Members this needs to apply. This article outlines a simple example. In reality, your security needs will be more complex. Having a defined plan from the start will make setting up access rights much easier.

Set 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, you have the correct permissions.

How does access rights setup work?

Access rights in Pigment are managed through the creation of rules, which are based on Metrics with an Access Rights data type. These Metrics are structured using the User List and any other Lists for which you want to restrict data access.

For example, if you want to provide different Members with access to specific Country data, the Metric must include both the User and Country Lists. When the Metric is properly configured, go to the Security settings and assign the Metric as a rule.

When setting up the rule, you must specify which Blocks in your Application the rule applies to—or explicitly exclude from it. You can choose to apply the rule to:

• Specific Metrics
• Specific List Properties
• All Metrics using particular Dimensions.

Create an access rights Metric

An access rights Metric is a Metric designed to define how Members interact with data. The number of access rights Metrics you need depends on your specific security requirements. These Metrics must have the Access Rights data type and be structured by the Member List and the Dimension List to which you want to apply data security.

For example, if you want to restrict Members to view data only for specific Products, the Metric should include both the Products Dimension and the Users list.

In most security setups, you will need multiple Metrics and can use functions like ACCESSRIGHTS to implement a more scalable solution.

You need the following requirements to create an access rights Metric:

• Data Type. Set to Access Rights.
• Users List. Must be included to apply different settings for different Members.
• Dimension List: A List to which security is applied must be included.

Access right data type

When you set a Metric to the access rights data type you’ll see three different options for both the read and write settings. 

Unspecified. You can apply multiple Metrics to set access rights for any given Dimension. Unspecified allows you to not affect any other setting.   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 hide data from a Member, you would set it to No Read / No Write.  To give a Member only read access, you would set it to Read/ No Write and to make it editable, you would set this to Read and Write.

This example shows an access rights Metric for Countries. It is structured by the Country and the User Lists. After creating a Metric, the next step is to apply it as an access rights rule. 

Assign an access rights Metric

After creating an access right Metric, you must apply it as a rule in the Security Settings page.  

1. From the sidebar, click the Settings Icon.
2. Click the Security label.
3. Go to the access rights section, click Add an access rights rule.
4. Select the access rights Metric.
5. Select the Rule type.
6. Select if the Read, Write, or Read and Write access for Members. 
7. Define where this rule should be applied..  

You can apply these rules to:

• Specific Metrics. Select one or more Metrics that contain the Dimensions used in your access rights Metric.
• All Metrics using specific Dimension(s). Assign this rule to all present and future Metrics that contain Dimensions used in your access rights Metric.
• Specific List Properties. Define on which Lists and on which Properties of this List these access rights should apply.
  For example, specific access rights for the Annual Salary property of my Employee list.

Multiple rules on the same Dimension

When there are multiple access rights rules applied to a Dimension, the most restrictive permission always prevails. The most restrictive permission is No Read / No Write. 

It is important to note that, by default, most Member 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.

If you look at the final possible configuration it shows Unspecified + Unspecified = No Read/ No Write, while this is true, in most cases there will already be an access right setting on Role, therefore that setting will be inherited.