Twproject integra un modello di sicurezza molto raffinato senza infastidire troppo né l’utente né l’amministratore per configurarlo.
Per capire la sicurezza di Twproject, ci sono alcuni punti chiave che saranno spiegati in questo capitolo.
Prima di tutto, la sicurezza di Twproject si basa sui ruoli; avere un ruolo significa ottenere un permesso per fare una certa operazione, per esempio creare un progetto, inserire worklog, leggere una risorsa. Chiamiamo questa abilità “permesso”; un ruolo è una collezione di permessi.
Ci sono due tipi di ruoli, “locali” e “globali”. Il ruolo locale, scelto quando una risorsa viene assegnata su un progetto definisce cosa questa risorsa può fare su quello specifico progetto.
Nell’assegnazione sopra è stato scelto il ruolo di project manager (ruolo locale), stai dando quindi alla risorsa il set di permessi associati al ruolo PM.
Lo scopo è quello di poter assegnare su un progetto, risorse con diritti diversi, potrai avere le risorse che con ruolo PM potranno gestire il progetto e risorse con il ruolo worker che avranno i diritti di Usare i ToDo ed inserire il worklog.
Ricorda che i diritti si propagano verso il basso nel progetto, se quindi sei assegnato come PM sulla radice del progetto, i diritti saranno validi su tutte le fasi di cui il progetto è composto.
In questo modo creerai una struttura di sicurezza molto raffinata, ma con alcune limitazioni, per esempio, per avere una supervisione su tutti i progetti in azienda dovremmo essere assegnati su tutti i progetti, scomodo no?
Per risolvere questo tipo di problema Twproject supporta anche ruoli “globali”. Un ruolo globale è assegnato ad una risorsa quando ad essa si associa una login e definisce (sempre attraverso un set di permessi) cosa questa risorsa può fare su tutti gli oggetti dell’area a prescindere dalle sue assegnazioni.
Quindi se un utente ha un ruolo globale con permesso “task read”, leggerà ogni progetto, saltando le assegnazioni.
Questo modello è molto raffinato e funziona bene nella maggior parte dei casi.
In alcune realtà però può essere necessario creare un livello ulteriore di sicurezza. Twproject introduce un oggetto più sofisticato chiamato “area”.
Un’area è una specie di “sandbox”, e tutti gli oggetti di Twproject appartengono ad un’ area. Oggetti da diverse aree non possono “vedersi” gli uni con gli altri (con alcune eccezioni), quindi per esempio se hai due aree, “produzione” e “contabilità”, puoi avere progetti, ruoli, tipi di progetto distinti, etc. .
Ovviamente avere due aree completamente separate può anche essere un problema, vedi per una singola azienda, dove probabilmente alcuni utenti dovrebbero essere cross-area. Twproject supporta anche questo tipo di soluzione, permettendoti di avere sullo stesso utente ruoli globali e assegnazioni da aree diverse.
Un’altra caratteristica interessante è la delega della gestione della sicurezza: in ogni area puoi avere una sorta di sub-amministratore, l’“area manager”, che è responsabile della creazione di nuovi utenti e dell’amministrazione dell’area.
Configurare questo tipo di ambiente è semplice ma non banale, noi suggeriamo vivamente di evitare la gestione multi-area fino a che non avrai capito davvero il modello di sicurezza di Twproject.
L’ultimo punto è come lavora la sicurezza per oggetti strutturati ad albero (come progetto o risorse); come detto sopra la sicurezza è propagata quindi se hai un permesso su un progetto, hai lo stesso permesso sui suoi discendenti.
Per riassumere come funziona la sicurezza, esamineremo un esempio di come Twproject risponde a questa domanda: l’utente U può aggiungere un ToDo alla fase T1.1. Ecco la struttura dell’esempio:
La risorsa U è assegnata su T1 con ruolo locale W(orker) che contiene alcuni permessi come leggi progetti, aggiungi/leggi/modifica ToDos, e altri. U non ha ruoli globali.
Questo è il flusso seguito da Twproject nel controllo della sicurezza, quando un controllo è vero il test si interrompe, altrimenti viene verificata la seguente clausola:
1) l’utente è proprietario del progetto T1.1 (cioè è stato lui a crearlo)? NO
2) l’utente è un amministratore? NO
3) l’utente ha un ruolo globale contenente il permesso “aggiungi ToDo”? NO
4) U è assegnato su T1.1 con un ruolo contenente il permesso “aggiungi ToDo”? NO, L’utente non è assegnato su T1.1
5) Infine controlla se T 1.1 ha un padre (SI) e se esiste sul padre una assegnazione con un ruolo che include il permesso richiesto (SI). Questo processo risale ricorsivamente fino alla radice alla ricerca di una assegnazione per U.
In questo semplice esempio viene trovato subito il padre con l’assegnazione e la risposta sarà quindi si, U può creare ToDo su T1.1
Fare questo tipo di test velocemente è stato davvero difficile.
Gli editor della sicurezza sono molto semplici, con rispetto verso il modello di sicurezza 🙂
Maggiori informazioni sulla sicurezza: