Wiki

Rollen & Admin-Panel

Das Administrationspanel von uVersion: wer es öffnen kann, die 9 Rollen, Super-Admin gegenüber project_admin, die Rang-Hierarchie und welcher Tab für wen verfügbar ist.

Einführung

Das Administrationspanel ist in den uVersion-Desktop-Client integriert. Es bündelt die Verwaltung von Benutzern, Gruppen, Berechtigungen, Validierungsregeln, Webhooks, Verteilung und den Dateien eines Repositorys. Diese Seite erklärt das Rollensystem, auf dem alles andere aufbaut: Lesen Sie sie vor den übrigen Seiten dieses Abschnitts.

Drei Begriffe tauchen überall auf. Ein Repository ist ein versioniertes Projekt auf dem Server. Eine Rolle ist die Bezeichnung, die ein Konto trägt (admin, artist, viewer…), und sie sagt, was dieses Konto tun darf. Eine Berechtigung sagt, auf welchen Ordnern es das tun darf.

Panel öffnen

1. Den Admin-Eintrag öffnen

Melden Sie sich im Desktop-Client mit einem Konto an, das eine Administrationsrolle hat, und öffnen Sie dann den Eintrag Admin in der Seitenleiste. Konten ohne Administrationsrolle sehen diesen Eintrag nicht. Zwei Rollen öffnen ihn: admin (Super-Administrator) und project_admin (Projektadministrator). Was sie dort sehen, ist nicht identisch: siehe den nächsten Abschnitt.

2. Die zwei Tab-Reihen erkennen

Unter dem Titel Admin Panel sind die Tabs in zwei Reihen angeordnet. Die obere, SERVER, betrifft den gesamten Server und hängt von keinem Projekt ab. Die untere, PROJECT, wirkt auf das Repository, das im Repository-Selektor am Anfang dieser Reihe ausgewählt ist: Ein Wechsel des Repositorys ändert, was diese Tabs anzeigen. Das ist das Erste, was zu prüfen ist, wenn ein Tab nicht das anzeigt, was Sie erwarten.

Das geöffnete Administrationspanel: der Titel Admin Panel, oben die Reihe SERVER und darunter die Reihe PROJECT mit vorangestelltem Repository-Selektor.

Super-Admin vs. project_admin

uVersion unterscheidet zwei Administrationsebenen:

Super-Admin (Rolle admin): Autorität über den gesamten Server. Er verwaltet alle Repositorys, alle Benutzer, die globalen Einstellungen, das Audit, die Lizenz.
project_admin: vollständiger Administrator, aber nur der Projekte, die er verwaltet. In seinen Repositorys tut er alles, was ein Admin tut (Berechtigungen, Regeln, Webhooks, GC, Auslöschung). Außerhalb seiner Repositorys hat er keinerlei Administrationsbefugnis.

Das Prinzip: Ein project_admin ist ein vollwertiger Administrator seiner eigenen Projekte und nichts anderswo. Deshalb ist sein Panel abgeschottet: Manche globalen Aktionen (siehe unten) bleiben dem Super-Admin vorbehalten.

Die 9 Rollen

Rolle	Wozu sie dient
`admin`	Super-Administrator: Vollzugriff, gesamter Server.
`project_admin`	Projektadministrator: vollständiger Admin seiner Repositorys, nichts anderswo.
`lead`	Teamleiter: Schreibzugriff auf alle Repositorys und mehrere erhöhte Capabilities (Freigabe, globale Aktivität, Verteilung). Heute faktisch eine sehr mächtige Rolle.
`artist`	Mitwirkender (Art): Check-out / Check-in von Dateien gemäß seinen Berechtigungen.
`programmer`	Mitwirkender (Code): Check-out / Check-in gemäß seinen Berechtigungen.
`qa`	Qualitätssicherung: trägt bei und nimmt an Reviews teil.
`user`	Generischer Mitwirkender.
`viewer`	Nur Lesen.
`playtester`	Zugriff nur auf veröffentlichte Builds (Spiel-Downloads). Sieht weder den Workspace noch die Repository-Dateien.

Die Rolle bestimmt die Macht, die Berechtigung bestimmt den Umfang Die Rolle sagt, was ein Konto tun kann (verwalten, beitragen, lesen). Die Berechtigungen sagen, auf welchen Ordnern. Ein artist kann nur die Pfade ändern, für die ihm Schreibzugriff gewährt wurde.

Ränge und Schutz

Die Rollen sind nach Rang geordnet: admin 100, lead 50, project_admin 40, programmer / artist / qa / user 10, viewer / playtester 5.

Ein project_admin kann nur eine Rolle strikt unter seinem eigenen Rang zuweisen: Er kann sich also weder selbst befördern noch selbst herabstufen, noch einen admin, einen lead oder einen anderen project_admin erstellen oder befördern.

Der Super-Admin ist die Obergrenze und hat keinen Gleichrangigen über sich Die Regel des strikt niedrigeren Rangs gilt nicht für ihn: Ein Super-Admin kann jede Rolle zuweisen, einschließlich admin, und auf einen anderen Super-Admin einwirken (ihn ändern oder löschen). Das ist notwendig, sonst wäre ein versehentlich erstellter zweiter Super-Admin nicht mehr zu entfernen.

Wer auf welchen Tab zugreift

Die Tabs der Reihe SERVER gelten für den gesamten Server. Die der Reihe PROJECT wirken auf das im Selektor am Anfang derselben Reihe gewählte Repository.

Tab	Reihe	Super-Admin	project_admin
Dashboard	SERVER	Ja	Nein
Repositories	SERVER	Ja	Nein
Users	SERVER	Vollständige Verwaltung	Erstellen und bearbeiten (E-Mail, Rolle); sieht alle Konten außer den Super-Admins
Groups	SERVER	Vollständige Verwaltung	Nein (Gruppen bleiben aus Permissions auswählbar)
Locks	SERVER	Alle Sperren des Servers	Ja, beschränkt auf seine Repositorys
Audit Log	SERVER	Ja	Nein
Distribution	SERVER	Ja	Nein (admin und lead vorbehalten)
Permissions	PROJECT	Ja	Ja, auf seinen Repositorys
Rules	PROJECT	Ja	Ja, auf seinen Repositorys
Webhooks	PROJECT	Ja	Ja, auf seinen Repositorys
Files	PROJECT	Ja	Ja, auf seinen Repositorys

Der Files-Tab hat zwei Ansichten Der Files-Tab trägt zwei Ansichten: Browse (die Dateien des Repositorys durchsuchen) und Storage (Speicherbelegung und Garbage Collection). Umgeschaltet wird über zwei Schaltflächen oben im Tab. Die Storage-Ansicht wird ausführlich in Speicher & GC beschrieben.

Der Files-Tab, Ansicht Browse aktiv: die beiden Schaltflächen Browse und Storage oben im Tab und darunter der Dateibaum des Repositorys.

Strikt nur Super-Admin: das Zurücksetzen des Passworts eines Benutzers, sein Löschen und der Umschalter Aktiv / Inaktiv, die Gruppenverwaltung, das Audit, das Dashboard und die Repository-Liste, die Verteilung, die Servereinstellungen, die globalen Statistiken und die Lizenz. Ein project_admin kann hingegen ein Konto erstellen und die E-Mail und Rolle von Konten, die keine Super-Admins sind, bearbeiten: siehe Benutzer.

Serverweite Capabilities

Eine Capability ist eine benannte Autorisierung (zum Beispiel „Builds veröffentlichen“, „Änderungen freigeben“), die an eine Rolle gebunden ist statt an eine Person oder einen Ordner. Wichtiger Punkt: Eine Capability gilt auf dem gesamten Server, sie hat keine Dimension pro Repository. Zwei praktische Folgen:

Ein lead, der die Capability manage_rules besitzt, hat serverweit Zugriff auf die Verteilung.
Ein project_admin besitzt keine Capability: Seine Autorität stammt aus der Liste der Projekte, die er verwaltet, nicht aus einer Capability. Das ist beabsichtigt, eine Capability kann nicht auf ein Projekt beschränkt werden.