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 des fichiers d'un dépôt. 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.

Trois mots reviennent partout. Un dépôt est un projet versionné sur le serveur. Un rôle est l'étiquette portée par un compte (admin, artist, viewer…) et il dit ce que ce compte a le droit de faire. Une permission dit sur quels dossiers il peut le faire.

Ouvrir le panneau

1. Ouvrir l'entrée Admin

Connectez-vous dans le client desktop avec un compte qui a un rôle d'administration, puis ouvrez l'entrée Admin dans la barre latérale. Les comptes sans rôle d'administration ne voient pas cette entrée. Deux rôles l'ouvrent : admin (super administrateur) et project_admin (administrateur de projet). Ce qu'ils y voient n'est pas identique : voir la section suivante.

2. Repérer les deux rangées d'onglets

Sous le titre Admin Panel, les onglets sont rangés en deux rangées. Celle du haut, SERVER, porte sur le serveur entier et ne dépend d'aucun projet. Celle du bas, PROJECT, agit sur le dépôt choisi dans le sélecteur de dépôt placé en tête de cette rangée : changer de dépôt change ce que ces onglets affichent. C'est la première chose à vérifier quand un onglet n'affiche pas ce que vous attendez.

Le panneau d administration ouvert : le titre Admin Panel, la rangee SERVER en haut, et en dessous la rangee PROJECT precedee du selecteur de depot.

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 project_admin ne peut attribuer qu'un rôle strictement en dessous de son propre rang : il ne peut donc ni s'auto-promouvoir, ni se rétrograder lui-même, ni créer ou promouvoir un admin, un lead ou un autre project_admin.

Le super admin est le plafond, et il n'a pas de pair au-dessus de lui La règle du rang strictement inférieur ne s'applique pas à lui : un super admin peut attribuer n'importe quel rôle, y compris admin, et agir sur un autre super admin (le modifier ou le supprimer). C'est nécessaire, sinon un second super admin créé par erreur serait impossible à retirer.

Qui accède à quel onglet

Les onglets de la rangée SERVER valent pour le serveur entier. Ceux de la rangée PROJECT agissent sur le dépôt choisi dans le sélecteur, en tête de cette même rangée.

Onglet	Rangée	Super admin	project_admin
Dashboard	SERVER	Oui	Non
Repositories	SERVER	Oui	Non
Users	SERVER	Gestion complète	Créer et modifier (email, rôle) ; voit tous les comptes sauf les super admins
Groups	SERVER	Gestion complète	Non (les groupes restent sélectionnables depuis Permissions)
Locks	SERVER	Tous les verrous du serveur	Oui, limité à ses dépôts
Audit Log	SERVER	Oui	Non
Distribution	SERVER	Oui	Non (réservé admin et lead)
Permissions	PROJECT	Oui	Oui, sur ses dépôts
Rules	PROJECT	Oui	Oui, sur ses dépôts
Webhooks	PROJECT	Oui	Oui, sur ses dépôts
Files	PROJECT	Oui	Oui, sur ses dépôts

L'onglet Files a deux vues L'onglet Files porte deux vues : Browse (parcourir les fichiers du dépôt) et Storage (occupation disque et garbage collection). La bascule se fait par deux boutons en haut de l'onglet. Le détail de la vue Storage est décrit dans Stockage & GC.

L onglet Files, vue Browse active : les deux boutons Browse et Storage en haut de l onglet, et l arborescence des fichiers du depot en dessous.

Restent strictement super admin : la réinitialisation du mot de passe d'un utilisateur, sa suppression et la bascule Actif / Inactif, la gestion des groupes, l'audit, le tableau de bord et la liste des dépôts, la distribution, les réglages serveur, les statistiques globales et la licence. Un project_admin peut en revanche créer un compte et modifier l'email et le rôle des comptes non super admin : voir Utilisateurs.

Capacités serveur-entier

Une capacité est une autorisation nommée (par exemple « publier des builds », « approuver des changements ») attachée à un rôle plutôt qu'à une personne ou à un dossier. Point important : une capacité vaut sur tout le serveur, elle n'a 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.