Ruoli

Comporre un ruolo

Un ruolo ha una key, un nome visualizzato e i permessi che selezioni da un elenco raggruppato per area: contenuti, modelli, file, operazioni, impostazioni, integrazioni e notifiche. I permessi sono specifici: pubblicare i contenuti è uno, e modificare un modello è un altro. La key non può cambiare dopo la creazione del ruolo. Un ruolo che non vuoi più viene disattivato, e i ruoli non vengono mai eliminati.

Due ruoli già pronti

Workspace administrator copre tutto nel workspace, inclusi fatturazione, progetti, inviti ed esportazione. Project administrator copre tutto dentro un progetto. L'applicazione dei controlli legge i permessi e mai il nome di un ruolo, quindi un ruolo che componi viene applicato esattamente come uno già pronto.

Dove si applica una concessione

Concedi un ruolo su tutto il workspace o su un progetto. Le concessioni si sommano, e una persona può avere più ruoli. Le persone entrano nel tuo team tramite invito, e ogni invito porta un ruolo. Una modifica al ruolo di qualcuno ha effetto al suo successivo aggiornamento di sessione.

Concedi solo ciò che hai

Ogni permesso in un ruolo che concedi deve essere uno che hai già. Un workspace mantiene sempre almeno un amministratore su tutto il workspace, e una revoca che ne lascerebbe zero viene rifiutata.

Ruoli per i tuoi utenti

Le persone che accedono alla tua applicazione hanno a loro volta dei ruoli. Li dichiari per progetto nel tuo file di configurazione o con foir customer-roles nella CLI (la documentazione chiama i tuoi utenti «customers»). I loro permessi sono scope, come eseguire una singola operazione o scrivere un modello.

Un ruolo contrassegnato come predefinito si applica a ogni utente senza un'assegnazione, e un utente senza ruolo ha un token di sola lettura. Un ruolo modificato raggiunge un utente autenticato al suo successivo aggiornamento del token, senza bisogno di accedere di nuovo. In un progetto con organizzazioni, un utente ha un ruolo in ciascuna organizzazione tramite un'appartenenza.