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 Speicher. Diese Seite erklärt das Rollensystem, auf dem alles andere aufbaut: Lesen Sie sie vor den übrigen Seiten dieses Abschnitts.

Panel öffnen

Das geöffnete Administrationspanel mit der Liste der Tabs (Benutzer, Gruppen, Berechtigungen, Regeln, Webhooks, Verteilung, Speicher).

Melden Sie sich im Desktop-Client mit einem Konto an, das eine Administrationsrolle hat, und öffnen Sie dann den Eintrag Admin in der Navigation. Konten ohne Administrationsrolle sehen diesen Eintrag nicht.

Zwei Rollen öffnen das Panel: admin (Super-Administrator) und project_admin (Projektadministrator). Was sie dort sehen, ist nicht identisch: siehe den nächsten Abschnitt.

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 Administrator kann nur auf ein Konto strikt unterhalb seines eigenen Rangs einwirken: Man kann sich also nicht selbst befördern, keinen Gleichrangigen ändern und sich nicht selbst unter seinen Rang herabstufen. Das verhindert zum Beispiel, dass ein project_admin (Rang 40) sich in einen Super-Admin verwandelt.

Wer auf welchen Tab zugreift

Tab	Super-Admin	project_admin
Benutzer	Vollständige Verwaltung	Nur Erstellung, abgeschottete Liste
Gruppen	Vollständige Verwaltung	Namen lesen (um eine Zuweisung zu adressieren)
Berechtigungen	Ja	Ja, auf seinen Repositorys
Regeln	Ja	Ja, auf seinen Repositorys
Webhooks	Ja	Ja, auf seinen Repositorys
Verteilung	Ja	Nein (admin und lead vorbehalten)
Speicher & GC	Ja	Ja, auf seinen Repositorys

Strikt nur Super-Admin: das Ändern / Zurücksetzen / Deaktivieren eines Benutzers, die Gruppenverwaltung (über das bloße Lesen hinaus), das Audit, die Servereinstellungen, die globalen Statistiken und die Lizenz.

Serverweite Capabilities

Manche Autorisierungen sind Capabilities, die an die Rolle gebunden und auf dem gesamten Server gültig sind (sie haben 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.