I permessi definiscono il livello di azione che un utente può avere.
Tipi di permessi:
- full: permesso completo di lettura + scrittura
- read: permesso di sola lettura
Relazione dei permessi
- utente > utente: un utente può avere permesso di lettura/scrittura su un altro utente (responsabilità diretta)
- utente > gruppo: un utente può avere permesso di lettura/scrittura su un gruppo (responsabilità indiretta su tutti i membri di un gruppo)
Permessi speciali:
- Forbidden: permesso speciale che esclude un utente da un insieme di permessi. Ad esempio, se abbiamo assegnato ad un coordinatore il permesso di lettura nei confronti di uno specifico gruppo ma vogliamo escludere un utente possiamo farlo assegnando al coordinatore un permesso “forbidden” nei confronti di quello specifico utente.
Logica di composizione dei permessi di un utente in accesso al sistema
All’accesso al sistema la logica indaga innanzitutto se è stato settato a valore 1 il superpermesso “forbidden” che permette ad un utente di accedere ma gli esclude ogni possibile permesso precedentemente creato. Questo serve a disabilitare temporaneamente i permessi utente senza distruggere la configurazione di un utente e poi doverla ricostruire. Il forbidden full è un override su tutte le altre logiche di composizione dei permessi.
Il sistema, poi, crea due distinti gruppi di permesso per l’ utente:
- completa lettura (BCD.user.permissions.read)
- completa scrittura (BCD.user.permissions.full)
e riempie questi insiemi con gli utenti con corrispondente permesso.
Di seguito il sistema controlla i permessi sui gruppi e integra i precedenti insiemi con i gruppi con permesso.
Il sistema, infine, controlla i fobidden singoli eventuali e distrugge eventuali users precedentemente inseriti nelle liste di permsso
La funzione BCD__iHavePermissionTo() è l’unica funzione (non lo è ancora ma lo sarà) che deve restituire un true/false per un qualunque permesso ad agire, deve quindi essere chiara e facilmente debuggabile.