We have an updated version of the Access Rights feature available.  This article answers some of the differences betwen the new versions. 

Table of Contents

How can I tell which version I am on?

The easiest way to see if you are on the legacy or current version is to check to see if there is an Unspecified option within the Default Access Rights option for a Role. 

To access the page, click on Settings from the sidebar in your application,  then select Roles, permissions & access.  Next, click on the Roles table and click New Role .  If you see Unspecified, this is the legacy version. 

The legacy version will also be listed under the Data access rights section of Roles, permissions & access.

What are the differences between them?

There is no loss of functionality or security features, and both versions are supported by Pigment.  The difference is that the current version does not have Unspecified in User Roles.  This requires a default read or write status to be defined in each Role.

They also handle Blank values in Access rights Metrics differently.  The legacy version will ignore these values.  The current version considers them a restrictive value similar to a No Read or No write.

What are the benefits of migrating?

The current Access rights handles each Access rights rule independently; which allows for multiple rules to be applied to a block while not leading to timeouts of Access rights formulas.

By having a default Read/Write settings for each Role and also treating blanks in Access rights metrics as a restrictive option (No Read or No Write), this new version increases auditability of your security model because of the need for default Access rights per Role.

Because blanks in Access rights metrics is a restrictive option in v2, you will have the option to use blank instead of false to restrict, which will result in sparser metrics and may benefit model performance. 

Lastly, all future product innovation, documentation, and training will be based on this version.

How do I know if I should migrate? 

There is no urgency to migrate at the moment as we are not planning to deprecate the Legacy version at the moment. In the event we do plan to deprecate the legacy version, we will inform you in advance with any steps required.

However at the current time, if you would like to review your current Access rights settings to evaluate if you want to migrate to the current version, these are different reasons you should consider migrating over.  Please consult your Solution Architect if you have questions related to them.

1. You want to apply multiple rules, each rule of which are independent and have low number of items in the dimensions within those rules. 
2. You've run into errors such as maximum cardinality exceeded and timeout in your Application in the past when applying multiple Access rights rules. 
3. You anticipate that your number of users will grow a lot in the next few months and your Access rights setup will need to grow with that. 
4. Your Access rights model is having issues e.g. Metrics are timing out when Access rights rules are applied onto them.

How can I migrate to the new version?

There are a few steps we will need to take in order to successfully migrate you over.

1. We need to do an internal audit of your workspace to determine the impact of switching to the new version.
2. We will liaise with you to identify the scope of the migration and which applications you would like to migrate to the new version.
3. We will have to work with you to rebuild the security model for the entire workspace.

Legacy Articles