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 archiviazione. Questa pagina spiega il sistema di ruoli su cui si basa tutto il resto: leggetela prima delle altre pagine di questa sezione.
Aprire il pannello
Accedete al client desktop con un account che ha un ruolo di amministrazione, poi aprite la voce Admin nella navigazione. Gli account senza ruolo di amministrazione non vedono questa voce.
Due ruoli aprono il pannello: admin (super amministratore) e project_admin
(amministratore di progetto). Ciò che vi vedono non è identico: vedere la sezione successiva.
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 amministratore può agire solo su un account strettamente al di sotto del proprio rango: non è quindi possibile autopromuoversi, né modificare un pari, né retrocedere se stessi al di sotto del proprio rango. È ciò che impedisce, per esempio, a un project_admin (rango 40) di trasformarsi in super admin.
Chi accede a quale scheda
| Scheda | Super admin | project_admin |
|---|---|---|
| Utenti | Gestione completa | Solo creazione, elenco compartimentato |
| Gruppi | Gestione completa | Lettura dei nomi (per indirizzare una concessione) |
| Permessi | Sì | Sì, sui suoi repository |
| Regole | Sì | Sì, sui suoi repository |
| Webhook | Sì | Sì, sui suoi repository |
| Distribuzione | Sì | No (riservato ad admin e lead) |
| Archiviazione & GC | Sì | Sì, sui suoi repository |
Restano strettamente di super admin: la modifica / reimpostazione / disattivazione di un utente, la gestione dei gruppi (oltre la semplice lettura), l'audit, le impostazioni del server, le statistiche globali e la licenza.
Capacità a livello di server
Alcune autorizzazioni sono capacità legate al ruolo e valide su tutto il server (non hanno 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.