{"id":3726,"date":"2017-12-19T14:56:16","date_gmt":"2017-12-19T14:56:16","guid":{"rendered":"https:\/\/twproject.com\/support\/?page_id=3726"},"modified":"2024-12-11T10:59:53","modified_gmt":"2024-12-11T10:59:53","slug":"sicurezza","status":"publish","type":"page","link":"https:\/\/twproject.com\/support\/it\/usare-twproject\/sicurezza\/","title":{"rendered":"Sicurezza"},"content":{"rendered":"

Twproject integra un modello di sicurezza molto raffinato senza infastidire troppo n\u00e9 l’utente n\u00e9 l’amministratore per configurarlo.<\/p>\n

Per capire la sicurezza di Twproject, ci sono alcuni punti chiave che saranno spiegati in questo capitolo.<\/p>\n

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\u00e0 \u201cpermesso\u201d; un ruolo \u00e8 una collezione di permessi.<\/strong><\/p>\n

\"\"Ci sono due tipi di ruoli, \u201clocali\u201d e \u201cglobali\u201d. Il ruolo locale, scelto quando una risorsa viene assegnata su un progetto definisce cosa questa risorsa pu\u00f2 fare su quello specifico progetto.<\/p>\n

\"\"<\/p>\n

Nell’assegnazione sopra \u00e8 stato scelto il ruolo di project manager (ruolo\u00a0locale<\/i>), stai dando quindi alla risorsa il set di permessi associati al ruolo PM.<\/p>\n

Lo scopo \u00e8 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.<\/p>\n

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 \u00e8 composto.<\/p>\n

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?<\/p>\n

Per risolvere questo tipo di problema Twproject supporta anche ruoli \u201cglobali\u201d. Un ruolo globale \u00e8 assegnato ad una risorsa quando ad essa si associa una login e definisce (sempre attraverso un set di permessi) cosa questa risorsa pu\u00f2 fare su tutti gli oggetti dell’area a prescindere dalle sue assegnazioni.<\/p>\n

Quindi se un utente ha un ruolo globale con permesso \u201ctask read\u201d, legger\u00e0 ogni progetto, saltando le assegnazioni.<\/p>\n

\"\"<\/p>\n

Questo modello \u00e8 molto raffinato e funziona bene nella maggior parte dei casi.<\/p>\n

In alcune realt\u00e0 per\u00f2 pu\u00f2 essere necessario creare un livello ulteriore di\u00a0 sicurezza. Twproject introduce un oggetto pi\u00f9 sofisticato chiamato \u201carea\u201d.<\/p>\n

Un’area \u00e8 una specie di \u201csandbox\u201d, e tutti gli oggetti di Twproject appartengono ad un’ area. Oggetti da diverse aree non possono \u201cvedersi\u201d gli uni con gli altri (con alcune eccezioni), quindi per esempio se hai due aree, \u201cproduzione\u201d e \u201ccontabilit\u00e0\u201d, puoi avere progetti, ruoli, tipi di progetto distinti, etc. .<\/p>\n

Ovviamente avere due aree completamente separate pu\u00f2 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.<\/p>\n

Un’altra caratteristica interessante \u00e8 la delega della gestione della sicurezza: in ogni area puoi avere una sorta di sub-amministratore, l’\u201carea manager\u201d, che \u00e8 responsabile della creazione di nuovi utenti e dell’amministrazione dell’area.<\/p>\n

Configurare questo tipo di ambiente \u00e8 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.<\/p>\n

L’ultimo punto \u00e8 come lavora la sicurezza per oggetti strutturati ad albero (come progetto o risorse); come detto sopra la sicurezza \u00e8\u00a0propagata<\/i>\u00a0quindi se hai un permesso su un progetto, hai lo stesso permesso sui suoi discendenti.<\/p>\n

Per riassumere come funziona la sicurezza, esamineremo un esempio di come Twproject risponde a questa domanda: l’utente U pu\u00f2 aggiungere un ToDo alla fase T1.1. Ecco la struttura dell’esempio:<\/p>\n

\"\"<\/p>\n

La risorsa U \u00e8 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.<\/p>\n

Questo \u00e8 il flusso seguito da Twproject nel controllo della sicurezza, quando un controllo \u00e8 vero il test si interrompe, altrimenti viene verificata la seguente clausola:<\/p>\n

1) l’utente \u00e8 proprietario del progetto T1.1 (cio\u00e8 \u00e8 stato lui a crearlo)? NO<\/p>\n

2) l’utente \u00e8 un amministratore? NO<\/p>\n

3) l’utente ha un ruolo globale contenente il permesso \u201caggiungi ToDo\u201d? NO<\/p>\n

4) U \u00e8 assegnato su T1.1 con un ruolo contenente il permesso \u201caggiungi ToDo\u201d? NO, L’utente non \u00e8 assegnato su T1.1<\/p>\n

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.<\/p>\n

In questo semplice esempio viene trovato subito il padre con l’assegnazione e la risposta sar\u00e0 quindi si, U pu\u00f2 creare ToDo su T1.1<\/p>\n

Fare questo tipo di test velocemente \u00e8 stato davvero difficile.<\/pre>\n
Gli editor della sicurezza sono molto semplici, con rispetto verso il modello di sicurezza \ud83d\ude42<\/p>\n
Maggiori informazioni sulla sicurezza:
\n\n\n