Wiki

Roles & admin panel

The uVersion administration panel: who can open it, the 9 roles, super admin versus project_admin, the rank hierarchy, and which tab is available to whom.

Introduction

The administration panel is built into the uVersion desktop client. It brings together the management of users, groups, permissions, validation rules, webhooks, distribution and storage. This page explains the role system that everything else relies on: read it before the other pages in this section.

Opening the panel

The administration panel open, showing the list of tabs (Users, Groups, Permissions, Rules, Webhooks, Distribution, Storage).

Sign in to the desktop client with an account that has an administration role, then open the Admin entry in the navigation. Accounts without an administration role do not see this entry.

Two roles open the panel: admin (super administrator) and project_admin (project administrator). What they see there is not identical: see the next section.

Super admin vs project_admin

uVersion distinguishes two levels of administration:

Super admin (role admin): authority over the whole server. It manages all repositories, all users, the global settings, the audit log, the licence.
project_admin: a full administrator, but only of the projects it administers. On its repositories it does everything an admin does (permissions, rules, webhooks, GC, obliteration). Outside its repositories it has no administration power.

The principle: a project_admin is a full administrator of its own projects, and nothing elsewhere. That is why its panel is compartmentalised: some global actions (see below) stay reserved for the super admin.

The 9 roles

Role	What it is for
`admin`	Super administrator: full access, whole server.
`project_admin`	Project administrator: full admin of its repositories, nothing elsewhere.
`lead`	Team lead: write access on all repositories and several elevated capabilities (approval, global activity, distribution). In practice a very powerful role today.
`artist`	Contributor (art): check-out / check-in of files according to its permissions.
`programmer`	Contributor (code): check-out / check-in according to its permissions.
`qa`	Quality assurance: contributes and takes part in reviews.
`user`	Generic contributor.
`viewer`	Read only.
`playtester`	Access to published builds only (game downloads). Sees neither the workspace nor the repository files.

The role defines the power, the permission defines the scope The role says what an account can do (administer, contribute, read). The permissions say on which folders. An artist can only modify the paths where write access was granted.

Ranks and guard

Roles are ordered by rank: admin 100, lead 50, project_admin 40, programmer / artist / qa / user 10, viewer / playtester 5.

An administrator can only act on an account strictly below its own rank: so no one can self-promote, modify a peer, or demote themselves below their rank. This is what prevents, for example, a project_admin (rank 40) from turning into a super admin.

Who can access which tab

Tab	Super admin	project_admin
Users	Full management	Creation only, compartmentalised list
Groups	Full management	Read the names (to target a grant)
Permissions	Yes	Yes, on its repositories
Rules	Yes	Yes, on its repositories
Webhooks	Yes	Yes, on its repositories
Distribution	Yes	No (reserved for admin and lead)
Storage & GC	Yes	Yes, on its repositories

Strictly super admin only: modifying / resetting / deactivating a user, group management (beyond simple reading), the audit log, server settings, global statistics and the licence.

Server-wide capabilities

Some authorisations are capabilities attached to the role and valid across the whole server (they have no per-repository dimension). Two practical consequences:

A lead, who holds the manage_rules capability, has access to Distribution across the whole server.
A project_admin holds no capability: its authority comes from the list of projects it administers, not from a capability. This is deliberate, a capability cannot be limited to a project.