Gruppi 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 l'utente appartenga ai gruppi corretti. Gli utenti che rientrano in un determinato gruppo possono visualizzare tutti e soli i dati associati agli asset abilitati per quel gruppo.

Il nome del gruppo 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 gruppo è 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'appartenenza a questo gruppo tutte le macchine che hanno tale valore nella chiave customerId del file configBE.json. Alcuni esempi del caso standard sono riportati nella tabella sottostante:

Gruppo	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:

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

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	Permesso per visualizzare gli asset che hanno le seguenti proprietà: customerId = client1 plant = plantMilan department = departmentA line = lineB
oapp-customer-client1-plantMilan-departmentB	Permesso per visualizzare gli asset che hanno le seguenti proprietà: customerId = client1 plant = plantMilan department = departmentB
oapp-customer-client1-plantMilan	Permesso per visualizzare gli asset che hanno le seguenti proprietà: customerId = client1 plant = plantMilan
oapp-customer-client1	Permesso per visualizzare gli asset che hanno le seguenti proprietà: customerId = client1

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.