Wiki

Rôles & panneau admin

Le panneau d'administration de uVersion : qui peut l'ouvrir, les 9 rôles, super admin contre project_admin, la hiérarchie de rangs, et quel onglet est accessible à qui.

Introduction

Le panneau d'administration est intégré au client desktop uVersion. Il regroupe la gestion des utilisateurs, des groupes, des permissions, des règles de validation, des webhooks, de la distribution et du stockage. Cette page explique le système de rôles sur lequel tout le reste s'appuie : lisez-la avant les autres pages de cette section.

Ouvrir le panneau

Le panneau d'administration ouvert, montrant la liste des onglets (Utilisateurs, Groupes, Permissions, Règles, Webhooks, Distribution, Stockage).

Connectez-vous dans le client desktop avec un compte qui a un rôle d'administration, puis ouvrez l'entrée Admin dans la navigation. Les comptes sans rôle d'administration ne voient pas cette entrée.

Deux rôles ouvrent le panneau : admin (super administrateur) et project_admin (administrateur de projet). Ce qu'ils y voient n'est pas identique : voir la section suivante.

Super admin vs project_admin

uVersion distingue deux niveaux d'administration :

Super admin (rôle admin) : autorité sur tout le serveur. Il gère tous les dépôts, tous les utilisateurs, les réglages globaux, l'audit, la licence.
project_admin : administrateur complet mais uniquement des projets qu'il administre. Sur ses dépôts, il fait tout ce qu'un admin fait (permissions, règles, webhooks, GC, obliteration). En dehors de ses dépôts, il n'a aucun pouvoir d'administration.

Le principe : un project_admin est un administrateur à part entière de ses propres projets, et rien ailleurs. C'est pourquoi son panneau est cloisonné : certaines actions globales (voir plus bas) restent réservées au super admin.

Les 9 rôles

Rôle	À quoi il sert
`admin`	Super administrateur : accès total, serveur entier.
`project_admin`	Administrateur de projet : admin complet de ses dépôts, rien ailleurs.
`lead`	Responsable d'équipe : écriture sur tous les dépôts et plusieurs capacités élevées (approbation, activité globale, distribution). De fait un rôle très puissant aujourd'hui.
`artist`	Contributeur (art) : check-out / check-in des fichiers selon ses permissions.
`programmer`	Contributeur (code) : check-out / check-in selon ses permissions.
`qa`	Contrôle qualité : contribue et participe aux revues.
`user`	Contributeur générique.
`viewer`	Lecture seule.
`playtester`	Accès aux builds publiés uniquement (téléchargement de jeux). Ne voit ni le workspace ni les fichiers du dépôt.

Le rôle définit le pouvoir, la permission définit la portée Le rôle dit ce qu'un compte peut faire (administrer, contribuer, lire). Les permissions disent sur quels dossiers. Un artist ne peut modifier que les chemins où on lui a accordé l'écriture.

Rangs et garde

Les rôles sont classés par rang : admin 100, lead 50, project_admin 40, programmer / artist / qa / user 10, viewer / playtester 5.

Un administrateur ne peut agir que sur un compte strictement en dessous de son propre rang : on ne peut donc pas s'auto-promouvoir, ni modifier un pair, ni se rétrograder soi-même en dessous de son rang. C'est ce qui empêche, par exemple, un project_admin (rang 40) de se transformer en super admin.

Qui accède à quel onglet

Onglet	Super admin	project_admin
Utilisateurs	Gestion complète	Création seulement, liste cloisonnée
Groupes	Gestion complète	Lecture des noms (pour cibler un grant)
Permissions	Oui	Oui, sur ses dépôts
Règles	Oui	Oui, sur ses dépôts
Webhooks	Oui	Oui, sur ses dépôts
Distribution	Oui	Non (réservé admin et lead)
Stockage & GC	Oui	Oui, sur ses dépôts

Restent strictement super admin : la modification / réinitialisation / désactivation d'un utilisateur, la gestion des groupes (au-delà de la simple lecture), l'audit, les réglages serveur, les statistiques globales et la licence.

Capacités serveur-entier

Certaines autorisations sont des capacités attachées au rôle et valables sur tout le serveur (elles n'ont pas de dimension par dépôt). Deux conséquences pratiques :

Un lead, qui détient la capacité manage_rules, a accès à la Distribution sur l'ensemble du serveur.
Un project_admin ne détient aucune capacité : son autorité vient de la liste des projets qu'il administre, pas d'une capacité. C'est délibéré, une capacité ne peut pas être limitée à un projet.