# Ruoli per Visibilità Asset

Gli asset in Homepage sono visualizzati rispettando i permessi che l'utente autenticato all'interno dell'applicazione possiede. Anche per visualizzare gli asset è necessario che all'utente vengano assegnati i ruoli corretti. Gli utenti a cui è assegnato un determinato ruolo possono visualizzare tutti e soli i dati associati agli asset abilitati per quel ruolo.

Il nome del ruolo può essere costruito facendo riferimento al file configBE.json dei vari asset oppure alle varie chiavi associate all'asset in fase di sua creazione. La costruzione del nome del ruolo è dinamica e composta da un prefisso ("oapp-customer-") e da una parte variabile: 

```
oapp-customer-{parte dinamica}
```

La parte dinamica della stringa può essere costruita seguendo due metodologie differenti.

Nel **caso standard**, al prefisso viene concatenata una stringa che rappresenta il *customerId* della macchina. Saranno visibili tramite l'assegnazione di questo ruolo tutte le macchine che hanno tale valore nella chiave *customerId* del file configBE.json. Alcuni esempi del caso standard sono riportati nella tabella sottostante:

| Ruolo                   | Permessi Associati                                                                  |
| ----------------------- | ----------------------------------------------------------------------------------- |
| oapp-customer-all       | Permessi per visualizzare i dati di tutti gli asset.                                |
| oapp-customer-40factory | Permessi per visualizzare gli asset configurati con *customerId* pari a  40factory. |
| oapp-customer-customer1 | Permessi per visualizzare gli asset configurati con *customerId* pari a customer1.  |

## Permessi gerarchici

Nel **caso personalizzato**, configurando in maniera corretta l'applicazione, è possibile rendere più complicato e potente il meccanismo di gestione della visibilità. L'idea è di utilizzare stringhe di lunghezza variabile, fino a un massimo di 63 caratteri, nel formato: 

{% code fullWidth="false" %}

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

{% endcode %}

Presa la parte variabile, si nota come sia costruita utilizzando una catena di chiavi in un determinato ordine. L'ordine delle chiavi deve essere definito all'interno del file di configurazione del Data Manager di tipo env, nella chiave "*storage\_environment*" - "*permissions\_hierarchy*".

In questo modo, presi i valori che tali chiavi assumono per i vari asset nel file configBE.json, è possibile comporre il permesso. Gli asset che presentano, per le chiavi indicate in configurazione, i valori presenti all'interno del permesso, saranno visibili. Le chiavi non indicate nel permesso non saranno controllate. 

Grazie a questo meccanismo è possibile garantire gli accessi ad asset con caratteristiche comuni e con un livello sempre maggiore di specializzazione e granularità. 

Di seguito è riportato un esempio di permessi personalizzati.

Il primo step consiste nel configurare il Data Manager in maniera corretta:

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

In questo esempio vogliamo utilizzare le chiavi "customerId", "plant", "department" e "line", in quest'ordine, per comporre i permessi. Tutte le macchine del progetto saranno descritte da queste chiavi nel file configBE.json .

A questo punto possono essere definiti i permessi a seconda dei valori disponibili per le chiavi specificate, per esempio:

| Gruppo                                             | Permessi Associati                                                                                                                                                                                 |
| -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| oapp-customer-client1-plantMilan-departmentA-lineB | <p>Permesso per visualizzare gli asset che hanno le seguenti proprietà:</p><ul><li>customerId = client1</li><li>plant = plantMilan</li><li>department = departmentA</li><li>line = lineB</li></ul> |
| oapp-customer-client1-plantMilan-departmentB       | <p>Permesso per visualizzare gli asset che hanno le seguenti proprietà:</p><ul><li>customerId = client1</li><li>plant = plantMilan</li><li>department = departmentB</li></ul>                      |
| oapp-customer-client1-plantMilan                   | <p>Permesso per visualizzare gli asset che hanno le seguenti proprietà:</p><ul><li>customerId = client1</li><li>plant = plantMilan</li></ul>                                                       |
| oapp-customer-client1                              | <p>Permesso per visualizzare gli asset che hanno le seguenti proprietà:</p><ul><li>customerId = client1</li></ul>                                                                                  |

{% hint style="danger" %}
Il DM effettua in automatico un parsing dei valori delle chiavi, secondo questa logica:

1. rimuove gli spazi;
2. rimuove il carattere "-";
3. trasforma tutto in lower case.

Per esempio, "Reparto A-123" diventerà "repartoa123".

Questa regola non vale per la chiave *customerId*.
{% endhint %}