Permessi e ruoli

Canopy utilizza un modello di permessi a tre livelli che combina il controllo degli accessi basato sui ruoli a livello di applicazione con ruoli stakeholder specifici per scheda. Questa pagina spiega il design, quando utilizzare ciascun livello e come i livelli si combinano per formare i permessi effettivi.

Perché tre livelli?

L'Architettura Aziendale è per natura trasversale. Una determinata scheda — ad esempio un'Application — potrebbe essere:

• Di sola lettura per la maggior parte degli utenti (i visualizzatori vedono l'inventario ma non possono modificare)
• Modificabile dal team generale di AE (i membri possono aggiornare qualsiasi scheda)
• Gestita da una persona specifica responsabile di quella applicazione (il Proprietario tecnico dell'applicazione può modificare e approvare lo stato, anche se non ha diritti di modifica a livello di tutta l'organizzazione)
• Completamente controllata dagli amministratori (che possono fare qualsiasi cosa)

Un sistema di ruoli piatto gestisce i primi tre casi ma non il quarto: o si concedono diritti di modifica a livello di organizzazione (troppo ampio) o nulla (troppo restrittivo). Il livello stakeholder risolve questo problema concedendo permessi per scheda a singoli individui nominati.

Livello 1 — Ruoli applicazione

I ruoli applicazione vengono assegnati agli utenti e si applicano all'intera piattaforma. Sono definiti e gestiti in Amministrazione → Utenti e ruoli.

Ogni ruolo porta un insieme di permessi JSON. I ruoli integrati sono:

Ruolo	Chiave	Ambito
Amministratore	admin	Carattere jolly {"*": true} — senza restrizioni
Amministratore BPM	bpm_admin	BPM completo + inventario completo, senza admin.*
Membro	member	Inventario completo + modifica BPM, senza admin.*
Visualizzatore	viewer	Sola lettura in tutti i domini

È possibile creare ruoli personalizzati con qualsiasi combinazione delle chiavi di permesso disponibili, raggruppate in domini come inventory.*, reports.*, bpm.*, ppm.*, grc.*, todos.*, admin.*.

Usare i ruoli applicazione quando è necessario controllare cosa può fare una categoria di utenti sull'intera piattaforma.

Livello 2 — Ruoli stakeholder

I ruoli stakeholder vengono assegnati agli utenti su schede specifiche. Ogni tipo di scheda definisce il proprio insieme di definizioni di ruoli stakeholder (ad es. le schede Application hanno «Proprietario tecnico dell'applicazione», «Proprietario aziendale dell'applicazione», «Data Steward»). Questi vengono configurati in Amministrazione → Metamodello → [tipo] → Ruoli stakeholder.

Ogni definizione di ruolo stakeholder porta un insieme di permessi a livello di scheda — come card.edit, card.approve, card.manage_relations. Quando un utente viene aggiunto come stakeholder su una scheda, ottiene quei permessi solo su quella scheda.

Usare i ruoli stakeholder quando la proprietà o la responsabilità è specifica per una scheda: il proprietario di una particolare applicazione deve poterla gestire senza ottenere diritti di modifica su tutte le altre 500 applicazioni.

Livello 3 — Permessi effettivi

Quando un utente tenta un'azione su una scheda, il sistema calcola i suoi permessi effettivi combinando:

1. I permessi del ruolo applicazione (mappati da chiavi a livello di piattaforma a chiavi a livello di scheda)
2. Tutti i permessi dei ruoli stakeholder che detiene su quella specifica scheda

Il risultato è l'unione di entrambi gli insiemi. Un utente che è Visualizzatore (a livello di piattaforma) ma Proprietario tecnico dell'applicazione su una scheda può modificare quella scheda, perché il ruolo stakeholder concede card.edit anche se il ruolo Visualizzatore non lo fa.

I permessi effettivi per l'utente corrente su una data scheda sono esposti tramite GET /cards/{id}/effective-permissions e controllano tutti i controlli di modifica, approvazione ed eliminazione nell'interfaccia utente.

Il carattere jolly dell'amministratore

Il ruolo Amministratore utilizza {"*": true} come insieme di permessi. Questo viene valutato come «consenti tutto» — inclusi i permessi che non esistevano quando il ruolo è stato creato. Ciò significa che i nuovi moduli e le nuove chiavi di permesso sono automaticamente disponibili per gli amministratori senza alcun aggiornamento del ruolo.

Nessun altro ruolo integrato utilizza il carattere jolly. Quando si creano ruoli personalizzati, usare chiavi di permesso esplicite anziché caratteri jolly — questo rende l'ambito del ruolo verificabile e previene concessioni eccessive accidentali.

Struttura delle chiavi di permesso

Tutte le chiavi di permesso seguono il pattern dominio.azione:

• inventory.view — leggere le schede
• inventory.edit — aggiornare le schede
• inventory.create — creare le schede
• admin.metamodel — gestire i tipi di scheda e i tipi di relazione
• admin.impersonate — agire temporaneamente come un ruolo diverso (vedere Impersonazione dei ruoli)
• bpm.approve — approvare versioni del flusso di processo BPMN
• todos.view / todos.create / todos.manage — accedere e gestire i task
• risks.manage — creare e aggiornare le voci del registro dei rischi

L'elenco completo delle chiavi valide si trova in backend/app/core/permissions.py, che è l'unica fonte di verità. Le nuove chiavi di permesso devono essere aggiunte lì prima di poter essere concesse a qualsiasi ruolo.

Schemi comuni

Limitare un modulo a un team: Creare un ruolo personalizzato con solo i permessi ppm.* e inventory.view. Assegnarlo al team di gestione del portafoglio progetti. Potranno lavorare in PPM ma non potranno modificare l'inventario principale.

Concedere diritti di approvazione senza diritti di modifica: Assegnare a uno stakeholder aziendale il ruolo di «Proprietario aziendale dell'applicazione» su schede Application specifiche. Configurare quel ruolo per includere card.approval_status ma non card.edit. Potrà approvare le schede che il team di AE ha popolato, ma non potrà modificare i dati.

Accesso di emergenza per un amministratore: Il carattere jolly dell'amministratore significa che qualsiasi permesso futuro — inclusi i permessi aggiunti da estensioni o versioni future — viene automaticamente concesso. Usare il ruolo Amministratore solo per gli utenti che hanno realmente bisogno di accesso illimitato.

Testare come un ruolo specifico: Gli utenti con admin.impersonate possono passare a qualsiasi ruolo non amministratore dal menu utente (Visualizza come ruolo…) per verificare esattamente cosa può vedere e fare quel ruolo — senza creare un account di test separato. La sessione di impersonazione è solo JWT e non lascia tracce sull'account sottostante. Vedere Impersonazione dei ruoli per il flusso di lavoro completo.

Vedere anche

• Utenti e ruoli — creazione e modifica dei ruoli applicazione
• Amministrazione del metamodello — configurazione dei ruoli stakeholder per tipo di scheda
• Dettaglio scheda: scheda Stakeholder — assegnazione degli stakeholder a una scheda