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”. I ruoli locali hanno lo scope di un progetto: questo significa che i permessi lavorano sul progetto su cui è impostato il ruolo (attraverso un’assegnazione). I ruoli locali sono assegnati alle risorse durante la fase di assegnazione; quindi quando assegni una risorsa su un progetto, per esempio, project manager (cioè un ruolo locale), stai dando alla risorsa il set di permessi associati al ruolo PM.
In questo modo creerai una struttura di sicurezza molto raffinata, ma con alcune limitazioni: l’impostazione dei permessi locali non consentirà, per esempio, a un supervisore di leggere tutti i dati del tuo progetto senza assegnarla/lo su ogni progetto, il che sarebbe una perdita di tempo.
Per risolvere questo tipo di problema Twproject supporta che ruoli “globali”. Un ruolo globale è un set di permessi che sono direttamente associati a una risorsa, non attraverso la mediazione di una assegnazione. 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, ma Twproject va oltre questo, e introduce un oggetto più sofisticato chiamato “area”. Un’area è una specie di “sandbox”, e quasi tutti gli oggetti di Twproject appartengono a una sola 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); di default la sicurezza è propagata quindi se hai un permesso su un progetto, hai lo stesso permesso sui suoi discendenti. Questo è il comportamento di default, ma questa impostazione è locale al nodo, per esempio progetti basati su Scrum possono avere configurazione diverse (su Scrum un cliente può aggiungere issue al backlog, ma non può interferire con Sprint, quindi in questo caso i permessi non sono propagati).
Riassumendo 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?
2) l’utente è un amministratore?
3) l’utente ha un ruolo globale nella stessa area del progetto T1.1 contenente il permesso “aggiungi ToDo”?
4) U è assegnato su T1.1 con un ruolo contenente il permesso “aggiungi ToDo”?
5) Infine controlla se il padre (T1) propaga i permessi e il figlio (T1.1) eredita. La risposta è “sì” di default così controllerà i passi 1-4 con T1.1 padre T1.
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: