Wiki
Ruoli e pannello di amministrazione
Il pannello di amministrazione di uVersion: chi può aprirlo, i 9 ruoli, super admin rispetto a project_admin, la gerarchia dei ranghi e quale scheda è disponibile per chi.
Introduzione
Il pannello di amministrazione è integrato nel client desktop di uVersion. Riunisce la gestione di utenti, gruppi, permessi, regole di validazione, webhook, distribuzione e i file di un repository. Questa pagina spiega il sistema di ruoli su cui si basa tutto il resto: leggetela prima delle altre pagine di questa sezione.
Tre parole ricorrono ovunque. Un repository è un progetto versionato sul server. Un
ruolo è l'etichetta che un account porta (admin, artist,
viewer…) e dice cosa quell'account ha il diritto di fare. Un permesso dice su quali
cartelle può farlo.
Aprire il pannello
1. Aprire la voce Admin
Accedete al client desktop con un account che ha un ruolo di amministrazione, poi aprite la voce
Admin nella barra laterale. Gli account senza ruolo di amministrazione non vedono questa voce. Due
ruoli la aprono: admin (super amministratore) e project_admin (amministratore di
progetto). Ciò che vi vedono non è identico: vedere la sezione successiva.
2. Individuare le due righe di schede
Sotto il titolo Admin Panel, le schede sono disposte su due righe. Quella in alto, SERVER, riguarda l'intero server e non dipende da alcun progetto. Quella in basso, PROJECT, agisce sul repository scelto nel selettore di repository posto all'inizio di quella riga: cambiare repository cambia ciò che queste schede mostrano. È la prima cosa da verificare quando una scheda non mostra ciò che vi aspettate.
Super admin vs project_admin
uVersion distingue due livelli di amministrazione:
- Super admin (ruolo
admin): autorità su tutto il server. Gestisce tutti i repository, tutti gli utenti, le impostazioni globali, l'audit, la licenza. - project_admin: amministratore completo, ma solo dei progetti che amministra. Sui suoi repository fa tutto ciò che fa un admin (permessi, regole, webhook, GC, obliterazione). Al di fuori dei suoi repository non ha alcun potere di amministrazione.
Il principio: un project_admin è un amministratore a pieno titolo dei propri progetti, e nient'altro altrove. Per questo il suo pannello è compartimentato: alcune azioni globali (vedere sotto) restano riservate al super admin.
I 9 ruoli
| Ruolo | A cosa serve |
|---|---|
admin | Super amministratore: accesso totale, tutto il server. |
project_admin | Amministratore di progetto: admin completo dei suoi repository, nient'altro altrove. |
lead | Responsabile del team: scrittura su tutti i repository e diverse capacità elevate (approvazione, attività globale, distribuzione). Di fatto oggi un ruolo molto potente. |
artist | Collaboratore (arte): check-out / check-in dei file secondo i suoi permessi. |
programmer | Collaboratore (codice): check-out / check-in secondo i suoi permessi. |
qa | Controllo qualità: contribuisce e partecipa alle revisioni. |
user | Collaboratore generico. |
viewer | Sola lettura. |
playtester | Accesso solo alle build pubblicate (download dei giochi). Non vede né il workspace né i file del repository. |
artist può modificare solo i percorsi in cui gli è stata concessa la scrittura.
Ranghi e guardia
I ruoli sono ordinati per rango: admin 100, lead 50, project_admin 40,
programmer / artist / qa / user 10,
viewer / playtester 5.
Un project_admin può assegnare solo un ruolo strettamente al di sotto del proprio
rango: non può quindi né autopromuoversi, né retrocedersi, né creare o promuovere un admin, un
lead o un altro project_admin.
admin, e agire su un altro super admin (modificarlo o eliminarlo). È
necessario, altrimenti un secondo super admin creato per errore sarebbe impossibile da rimuovere.
Chi accede a quale scheda
Le schede della riga SERVER valgono per l'intero server. Quelle della riga PROJECT agiscono sul repository scelto nel selettore, all'inizio della stessa riga.
| Scheda | Riga | Super admin | project_admin |
|---|---|---|---|
| Dashboard | SERVER | Sì | No |
| Repositories | SERVER | Sì | No |
| Users | SERVER | Gestione completa | Creare e modificare (email, ruolo); vede tutti gli account tranne i super admin |
| Groups | SERVER | Gestione completa | No (i gruppi restano selezionabili da Permissions) |
| Locks | SERVER | Tutti i blocchi del server | Sì, limitato ai suoi repository |
| Audit Log | SERVER | Sì | No |
| Distribution | SERVER | Sì | No (riservato ad admin e lead) |
| Permissions | PROJECT | Sì | Sì, sui suoi repository |
| Rules | PROJECT | Sì | Sì, sui suoi repository |
| Webhooks | PROJECT | Sì | Sì, sui suoi repository |
| Files | PROJECT | Sì | Sì, sui suoi repository |
Restano strettamente di super admin: la reimpostazione della password di un utente, la sua eliminazione e l'interruttore Attivo / Inattivo, la gestione dei gruppi, l'audit, la dashboard e l'elenco dei repository, la distribuzione, le impostazioni del server, le statistiche globali e la licenza. Un project_admin può invece creare un account e modificare l'email e il ruolo degli account che non sono super admin: vedere Utenti.
Capacità a livello di server
Una capacità è un'autorizzazione con nome (per esempio «pubblicare build», «approvare modifiche») legata a un ruolo anziché a una persona o a una cartella. Punto importante: una capacità vale su tutto il server, non ha una dimensione per repository. Due conseguenze pratiche:
- Un
lead, che detiene la capacitàmanage_rules, ha accesso alla Distribuzione su tutto il server. - Un
project_adminnon detiene alcuna capacità: la sua autorità deriva dall'elenco dei progetti che amministra, non da una capacità. È deliberato, una capacità non può essere limitata a un progetto.