Ruoli & permessi

CodeCourier usa un sistema di controllo degli accessi basato sui ruoli (RBAC) con tre ruoli distinti: Owner, Admin e Member. Ogni ruolo eredita tutti i permessi dei ruoli sottostanti, creando una gerarchia chiara. Questa pagina documenta esattamente cosa può fare ogni ruolo e fornisce raccomandazioni per l’assegnazione dei ruoli.

Gerarchia dei ruoli

Il modello dei permessi segue una gerarchia rigorosa:

Owner > Admin > Member

Ogni ruolo include tutti i permessi dei ruoli sottostanti. Un Owner può fare tutto ciò che può fare un Admin, e un Admin può fare tutto ciò che può fare un Member.

Definizioni dei ruoli

Owner

L’Owner è il creatore del progetto e ha accesso senza restrizioni a tutte le funzionalità e impostazioni. Un progetto ha sempre almeno un proprietario, e questo vincolo viene applicato a livello di database - l’ultimo proprietario rimasto non può essere rimosso né retrocesso.

Capacità esclusive dell’Owner:

• Cambiare il ruolo di qualsiasi membro (inclusa la promozione di altri a Owner)
• Rimuovere altri proprietari dal progetto
• Eliminare interamente il progetto
• Trasferire la proprietà promuovendo un altro membro e retrocedendo se stesso

Admin

Gli Admin sono membri fidati del team che possono gestire le operazioni quotidiane del progetto, inclusa la gestione dei membri e la configurazione delle impostazioni. Hanno quasi tutti i permessi di un Owner, tranne i cambi di ruolo e le azioni distruttive a livello di proprietario.

Capacità dell’Admin (oltre a quelle del Member):

• Invitare nuovi membri al progetto
• Rimuovere membri dal progetto (tranne i proprietari)
• Annullare gli inviti in sospeso
• Configurare le impostazioni del progetto (chiavi API, prompt di sistema, variabili d’ambiente)

Member

I Member sono partecipanti regolari del team che possono usare tutte le funzionalità del progetto ma non possono gestire il team né le impostazioni critiche. Questo è il ruolo predefinito per i nuovi inviti.

Capacità del Member:

• Visualizzare tutte le risorse del progetto (sandbox, run, workflow, personas, issue session, learning)
• Creare e gestire le proprie sandbox e i propri run
• Creare e configurare workflow e personas
• Avviare e gestire le issue session
• Visualizzare e accettare/rifiutare i propri inviti
• Visualizzare l’elenco dei membri
• Accedere ai dati di analytics e utilizzo del progetto

Matrice dei permessi

Meccanismo di applicazione

I permessi vengono applicati lato server in ogni query e mutation Convex. Il backend usa funzioni helper di autenticazione condivise che verificano sia l’identità che l’autorizzazione prima di eseguire qualsiasi operazione:

• getProjectForMember(ctx, projectId) - Verifica che l’utente corrente sia un membro attivo (non in sospeso) del progetto. Usata dalle query che richiedono l’accesso di base al progetto.
• requireProjectAdmin(ctx, projectId) - Verifica che l’utente corrente sia un admin o un proprietario del progetto. Usata dalle mutation che gestiscono i membri e le impostazioni.
• requireProjectOwner(ctx, projectId) - Verifica che l’utente corrente sia un proprietario del progetto. Usata dalle mutation che cambiano i ruoli ed eseguono operazioni distruttive.

Questi controlli vengono eseguiti a ogni richiesta, garantendo che anche se il frontend non riesce a nascondere un pulsante, il backend rifiuti le operazioni non autorizzate.

Vincoli di sicurezza

Diverse regole di sicurezza prevengono scenari di blocco accidentale:

• Protezione dell’ultimo proprietario - Se rimane un solo proprietario, quel proprietario non può essere rimosso né retrocesso. Il sistema controlla il numero di proprietari prima di consentire una retrocessione o una rimozione.
• Protezione dall’auto-retrocessione - Un proprietario può retrocedere se stesso, ma solo se c’è almeno un altro proprietario per mantenere la governance del progetto.
• Protezione dalla rimozione tra ruoli - Un admin non proprietario non può rimuovere un proprietario. Solo i proprietari possono rimuovere altri proprietari.

Best practice

Inizia con il privilegio minimo

Assegna il ruolo Member per impostazione predefinita quando inviti nuovi utenti. Promuovi ad Admin solo quando la persona deve gestire il team o configurare le impostazioni del progetto. Riserva il ruolo Owner agli utenti che necessitano del controllo completo del progetto.

Mantieni più proprietari

Per i progetti di produzione, assegna almeno due proprietari. Questo garantisce che l’accesso al progetto sia mantenuto anche se un proprietario diventa non disponibile. Consente inoltre il trasferimento della proprietà senza intervento esterno.

Rivedi regolarmente l’appartenenza

Rivedi periodicamente l’elenco dei membri e rimuovi gli utenti che non necessitano più dell’accesso. A differenza di alcuni sistemi, CodeCourier non ha una scadenza automatica dei ruoli, quindi una revisione manuale è l’approccio raccomandato.

Prossimi passi