Roles for Asset Visibility

It is possible to define some roles to manage asset visibility. Users who are assigned specific roles can only view data associated with assets enabled for that role.

The construction of the role name is dynamic and consists of a prefix and a variable part:

• prefix: "oapp-customer-";

• variable part: "customerId" where the string "customerId" will be associated with the asset during its creation.

Some examples are provided in the table below:

Roles	Associated Permissions
oapp-customer-all	Permission to view data for all assets.
oapp-customer-40factory	Permission to view assets configured with customerId equal to 40factory.
oapp-customer-customer1	Permission to view assets configured with customerId equal to customer1.

Hierarchical Roles

In the customized case, by properly configuring the application, it is possible to make the visibility management mechanism more complex and powerful. The idea is to use strings of variable length, up to a maximum of 63 characters, in the following format:

oapp-customer-{key1}-{key2}-{key3}-...-{keyN}

Taking the variable part, we can see that it is built using a chain of keys in a specific order. The order of the keys must be defined within the Data Manager configuration file of type env, under the key:

"storage_environment" - "permissions_hierarchy".

In this way, by taking the values that these keys assume for different assets in the configBE.json file, it is possible to compose the permission string. Assets that contain the values specified in the permission for the configured keys will be visible. Keys that are not specified in the permission will not be checked.

Thanks to this mechanism, access can be granted to assets with common characteristics while ensuring an increasingly specialized and granular level of access control.

Below an example of customized permissions.

The first step is to correctly configure the Data Manager:

"storage_environment": {
    "permissions_hierarchy": [
        "customerId",
        "plant",
        "department",
        "line"
    ],
    "otherKeys": "..."
}

In this example, we want to use the keys "customerId", "plant", "department", and "line", in this order, to compose the permissions. All machines in the project will be described using these keys in the configBE.json file.

At this point, permissions can be defined based on the available values for the specified keys. Examples:

Gruppo	Permessi Associati
oapp-customer-client1-plantMilan-departmentA-lineB	Permission to view assets that have the following properties: customerId = client1 plant = plantMilan department = departmentA line = lineB
oapp-customer-client1-plantMilan-departmentB	Permission to view assets that have the following properties: customerId = client1 plant = plantMilan department = departmentB
oapp-customer-client1-plantMilan	Permission to view assets that have the following properties: customerId = client1 plant = plantMilan
oapp-customer-client1	Permission to view assets that have the following properties: customerId = client1

The Data Manager automatically parses the values of the keys according to the following rules:

• removes spaces;

• removes the "-" character;

• converts everything to lowercase.

For example, "Plant A-123" diventerà "planta123".

This rule does not apply to the customerId key.