uVersion
Italiano
Scarica →

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

Il pannello di amministrazione aperto, con l'elenco delle schede (Utenti, Gruppi, Permessi, Regole, Webhook, Distribuzione, Archiviazione).

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

RuoloA cosa serve
adminSuper amministratore: accesso totale, tutto il server.
project_adminAmministratore di progetto: admin completo dei suoi repository, nient'altro altrove.
leadResponsabile del team: scrittura su tutti i repository e diverse capacità elevate (approvazione, attività globale, distribuzione). Di fatto oggi un ruolo molto potente.
artistCollaboratore (arte): check-out / check-in dei file secondo i suoi permessi.
programmerCollaboratore (codice): check-out / check-in secondo i suoi permessi.
qaControllo qualità: contribuisce e partecipa alle revisioni.
userCollaboratore generico.
viewerSola lettura.
playtesterAccesso solo alle build pubblicate (download dei giochi). Non vede né il workspace né i file del repository.
Il ruolo definisce il potere, il permesso definisce l'ambito Il ruolo dice cosa un account può fare (amministrare, contribuire, leggere). I permessi dicono su quali cartelle. Un 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

SchedaSuper adminproject_admin
UtentiGestione completaSolo creazione, elenco compartimentato
GruppiGestione completaLettura dei nomi (per indirizzare una concessione)
PermessiSì, sui suoi repository
RegoleSì, sui suoi repository
WebhookSì, sui suoi repository
DistribuzioneNo (riservato ad admin e lead)
Archiviazione & GCSì, 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_admin non 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.