Pigment & Sports Prediction App: an Access Rights Story [Legacy]

This article will provide you with a practical and simple use-case of Access Rights (AR) setup while expanding your knowledge of Pigment’s possibilities after you (finally) understand the multi-dimensionality concept and how easy it is to build anything on it, business-related or not 😉
 

Table of Contents

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

 

Introduction

Let’s take the Sports Prediction app, for example, which was built during the FIFA World Cup 2022 and will soon be available in our Templates Library so you can have fun and play with your peers and colleagues in the next big sports event, meanwhile, you can ask your CSM to bring a copy into your workspace.

The focus here, as already said, will be on Access Rights. The Sports Prediction app will have a self-explanatory Configuration Board on how to set it up.

But we will use it as the practical example in this article as, in order to set up the Access Rights properly in any application that has been built, first we need to understand:

• What has been built (blocks); and
• Who needs access (users/roles) and to what (blocks)

Application Overview

The FIFA World Cup 2022 - Live Version application is structured as follows:

The purpose of understanding the application’s architecture is to start identifying which parts of the application will concern Admins only and which parts were built so the End-Users can interact with the application.

Even if you don’t know this app, it’s easy to spot that, most likely, folder 04. Predictions (PRE) is the one where we will find the blocks built so the end-users can make their inputs (predictions).

It’s also important to understand the Dimensions being used in most of the Metrics’ structures as this is a key component for the creation of Access Rights rules.

The main Dimensions of this application are the following:

Setting Up the Roles

When comes to Access Rights you need to be able to identify which types of Roles you will need within your workspace/application (Admin, CFO, Controllers, BU Managers, etc) which will, later on, be assigned to the Users.

This application will require only two (2) types of Roles:

• Admin
• Participant

Now that the Roles are identified we need to create and set them up in the recently updated Roles, permissions & access settings area of the application:

The Admin role will come, by default, with All permissions to the Application, Blocks and Boards and with both Read and Write access.

For the Participant role, we will customize this setup and leave the minimum configuration needed by default which will be further complemented with the additional layers of Access Rights rules (ARM_Metrics) that will be created in Step 4.

So, in this case, the Participant role will be set up like this:

• Application permissions: Display Application
• Blocks permissions: None
• Board permissions: Can comment
• Read Application data: Read (for this application it’s ok to give Read to everyone, but sometimes it wouldn’t be recommended, therefore you could also set this to Unspecified and create specific rules for Read rights as well)
• Write Application data: Unspecified (because this Access Right will be defined by the rules that will be created in the next steps)

Identifying the Target Blocks

Thanks to the naming convention applied during the build of this application it’s easy to understand that within folder 04. Predictions (PRE) we have only two (2) Metrics where the Participants will need to make their inputs:

These two metrics are structured by the following dimensions:

• DIM_Match
• DIM_Participants

Creating the Access Rights Rules

Ok, we understand the application structure, we set up the Roles and identified the blocks that we will need to apply Access Rights rules to, so it’s time to get our hands dirty 🙃

First step, we need to assign/map the Participants to the Users and in order to do that you have two possibilities:

1. The most common and versatile one - the one being used in this example - is via a Metric with the Data type set as Boolean (ARM_Mapping_Participant to User) structured by both Participants and User dimensions.

2. The other option would have been to do this directly in the dimension DIM_Participants mapping 1 Participant to 1 User (1:1), which for the use-case of this application would work as well.
 

Now, based on the first step we will create the Access Right metric which will be a Metric with the Data type set as Access Rights (ARM_User_Access to Participants) and also structured by both Participants and User dimensions.

Applying the Access Rights Rules

Great! Now that the rule has been created lets apply it to the target metrics:

1. Go back to the Roles, permissions & access settings area of the application
2. Select the Data access rights tab
3. Click on “+ Add an access right rule”
4. Select the Rule type that you want to apply (Read & Write for this case)
5. Choose an access rights Metric (ARM_User_Access to Participants)
6. For this use case, we will Apply the rule to Specific Metric(s)
7. Which will be applied to those 2 pre-identified Input metrics (step 3)
8. Save the new rule

That’s it, you’re all set and ready to go!

Have fun and don’t forget to do some testing before rolling it out!

Next steps

To expand even more your knowledge, if you still didn’t do so, please go ahead and take a look at the following articles:

• Setting Up Security: Access rights & Permissions, the Practical Guide
• Setting Up Security: Centralized User Access, the Practical Guide
• Granting access to Boards with Board Permissions