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:
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:
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:
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:
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:
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:
rimuove gli spazi;
rimuove il carattere "-";
trasforma tutto in lower case.
Per esempio, "Reparto A-123" diventerà "repartoa123".
Questa regola non vale per la chiave customerId.