In Pigment, access rights are defined at the Application level through the User roles Metric and customized by access rights rules and options.

Here we answer some frequently asked questions when implementing an access rights configuration. 

Prerequisite reading

 We recommend that you read and understand the following topics - they cover the essential basics for understanding access and permissions in Pigment:

• Pigment Access Basics. Provides an overview of access levels in Pigment, and a high-level approach to identifying what is needed before granting access and permissions to Members.
• About Roles, Permissions, and Access Rights. Defines the relationships between Roles, permissions and access rights in Pigment, and explains the Roles, permissions and access page.
• Introduction to Access Rights. Explains the basics of access rights in Pigment, available access rights options, and their scope.

How do Roles impact access rights?

Roles determine a Member's default access rights within a Pigment Application. Every Member must be assigned a Role to access an Application, and this Role defines their initial Read and Write permissions.

These default Role permissions serve as the baseline, which you can further enforce with additional access rights rules. This allows more granular control over what Members can view or edit within the Application. For more information, see Introduction to Access Rights.

When assigning a Role to a Member, keep in mind that the most restrictive access always takes precedence over less restrictive access for any given data.

Let’s say you set a Member’s Role to Write access, you’ll need additional rules to restrict what can be written.

Conversely, if you set the Role to No Write access, you'll need two extra rules:

• one rule to state where the Member Role doesn’t apply
• a second rule to define writable areas

This same approach applies when applying Read and No Read permissions.

How does access rights inheritance impact access at Application level?

Access rights inheritance in Pigment allows you to create an access rights rule for a Block, which is then automatically applied to all other Blocks that reference it.

Before deciding to use access rights inheritance in your Pigment access plan, it's important to fully understand it. You need to know how to manage it and the options available to you if you decide to apply it to your model.

Access rights inheritance can simplify configuration by requiring fewer Metrics, however it also reduces transparency. For example, its frequently used by modelers with an expert understanding of their models who want to as few Metrics as possible,

If your model is complex with many dependencies, it can be difficult to predict how access rights will be inherited throughout the model. This often leads to unexpected behaviors and makes auditing and debugging difficult. To avoid this, it's better to apply access rights directly to all Blocks that use a specific Dimension.

For more information on access rights inheritance, see:

• Modeling principle MP10 - Use Access Rights Rules to Build Security, not Access Rights Inheritance in the Pigment Modeling Palette.
• Understand Access Rights Inheritance
• Use the RESETACCESSRIGHTS Function
• Options for Application-level Access Rights Inheritance

Can Members have the same Role - but different access rights configurations?

Yes. Default access rights are defined at Role level, while access rights rules are set at individual level. This allows Members with the same Role to have different access rights configurations. Before you set up an access rights Metric, it’s crucial to clearly define its overall objective.

For example, consider two Members with the Role Country Manager. The Role has default access rights, but you can set up additional access rights rules so that one Member can read data in the US, while the other can read data in France.

When you create an access rights Metric to serve as the access rights rule, ensure the following conditions are met:

• The data type must be set to Access rights.
• A User list is required to configure different settings for individual Members. • You must include a the Dimension List, which indicates where the security is applied.

Remember: default Role permissions serve as the baseline, and additional access rights rules add another layer of permissions to your Role.

For more information, see Introduction to Access Rights.

How are access rights Metrics used to configure data access rules?

When setting up an access rights Metric to configure a Rule, you specify the data access rule it assigns to Members. This is Read access, Write access, or a combination of both.

For example, if you create a rule with only Read access, Pigment ignores the Write setting in your Metric, regardless of how it is set up in the Users role Metric.

It’s common to use an access right Metric across multiple access rules, so it’s crucial to maintain a consistent naming convention for your Blocks to ensure clarity and organization.

For more information, see Create an Access Rights Metric and Rules. 
 

How do I populate data in an access right Metric?

The most scalable way to populate an access rights Metric is to create additional Metrics and reference them with the ACCESSRIGHTS formula. For example, one Metric might control Read access and another might control Write access.

For more information, see ACCESSRIGHTS Function.

How can I effectively manage my access rights Metrics?

It's a good practice to display these Metrics on a Board designed specifically for Admins for easy management.

However, the visibility of the data in these Metrics are still subject to the access rights rules you've created.

For example:

• If a Metric’s data visibility setting is set to Public, every Member in the Workspace can read the data, regardless of the Board it's on.

This setting overrides all other access rights configurations, and allows all Members with access to the Application to read data in that Block. Keep in mind that inherited Access Rights still apply.

• If a Metric’s data visibility is based on rules, only Members with qualifying access rights rules can view its data.

For more information on creating an admin Board, see MP05 - Create Admins Boards for Maintenance & Documentation.

Where should I apply access rights configurations?

It’s important to plan exactly where you want to control access to your data, whether it’s on a Transaction or Dimension List, or on a Metric.

• Transaction or Dimension List data access. The most common access rights configuration is managing permissions for Lists. Are you applying access rights to the Item’s values, or to Properties on that List?
• Metric data access. Do you want to apply it to all Metrics containing specific Dimensions, or to other select Metrics?

In all cases, it's important to remember the impact of access inheritance. If access inheritance is activated, and you have an access rights rule on an Item’s Property, this means all Metrics that reference it, will inherit that configuration.

For more information, see About Access Rights Inheritance and the RESETACCESSRIGHTS Function.

Can I override default access rights assigned to a Member Role ?

Before you decide to override the default access rights specified in the Users roles Metric, keep in mind that the most restrictive rule always prevails. This means that any rule that prevents data access takes priority over a rule that allows data access.

A Blank setting is also restrictive and can override Read or Write permissions, resulting in No Read or No Write access . This is explained in greater detail below.

For this reason, if a Role's default access is set to Read and No Write, and if you want to override this setting to Read and Write, which are less restrictive access settings, you need to create an additional rule to allow Read or Write access.

Let’s say you you want to change a Members Role’s default access rights from No Write to Write for a specific Metric.

To do this, you’ll need to override the Role's default access settings:

• First, create an access rule which specifies that the Role's default access does not apply to the specific Metric.
• Next, configure a new rule that grants Write or Read access to the selected Metric for the Members with the previously restricted Users Roles.