Wiki

Berechtigungen

Einer Gruppe oder einem Benutzer read / write / none Zugriff auf Ordner eines Repositorys gewähren. Muster, Priorität, Standardauflösung, Berechtigungstest.

Einführung

Die Registerkarte Permissions legt für ein bestimmtes Repository fest, wer in welchen Ordnern lesen oder schreiben darf. Eine Berechtigung richtet sich an eine Gruppe oder einen Benutzer, gilt für ein Pfadmuster und trägt eine Stufe (write / read / none). Die Rolle sagt, was ein Konto tun darf; die Berechtigung sagt, für welche Dateien.

Zugriff und Rollen

Die Registerkarte steht dem Super-Admin (alle Repositories) und dem project_admin (die von ihm verwalteten Repositories) zur Verfügung. Regeln sind immer an das ausgewählte Repository gebunden.

Die drei Stufen

Stufe	Wirkung
`write`	Lesen und Schreiben (Check-out, Check-in) auf den abgedeckten Pfaden.
`read`	Nur Lesen: kann synchronisieren, nicht ändern.
`none`	Kein Zugriff: verbirgt einen Ordner ausdrücklich, selbst wenn eine breitere Regel ihn erlauben würde.

Zugriff gewähren

Der Ordnerbaum mit den dreistufigen Kästchen, dem Gruppen-/Benutzer-Auswahlfeld und der Stufenleiste write/read/none.

Wählen Sie das Repository und dann die Registerkarte Permissions.
Wählen Sie im Auswahlfeld das Subjekt: eine Gruppe oder einen Benutzer (zwei Unterlisten "Groups" und "Users"). Eine Regel betrifft das eine oder das andere, niemals beide.
Markieren Sie im Ordnerbaum die betroffenen Ordner (die Kästchen haben drei Zustände: alles / teilweise / nichts). Ein Suchfeld filtert den Baum.
Wählen Sie in der eingeblendeten Leiste die Stufe (write / read / none) und klicken Sie auf Apply.

Die aktiven Regeln des Subjekts werden in einer Tabelle (Muster, Stufe, Priorität) angezeigt, in der Sie sie einzeln löschen können.

Nach Benutzername gewähren

Mit der Schaltfläche "+ By username" können Sie jemandem Zugriff gewähren, der nicht in der sichtbaren Liste erscheint, indem Sie seinen exakten Namen eingeben. So gewähren Sie einem Konto außerhalb Ihres üblichen Bereichs Zugriff, zum Beispiel einem playtester, der noch keine Berechtigung besitzt.

Der Name muss exakt übereinstimmen (kein Präfix). Das Feld gibt nur die Kennung und den Namen zurück, niemals die Rolle, damit es nicht zum Aufspüren bestehender Konten dient.

Muster und Priorität

Ein markierter Ordner Foo/Bar wird zum Muster Foo/Bar/** (der Ordner und alles, was er enthält, in beliebiger Tiefe). Die Wurzel des Repositorys wird zu /**.

Jede Regel erhält eine automatische Priorität gleich der Tiefe des Ordners (Anzahl der Segmente, Wurzel = 0). Eine spezifischere (tiefere) Regel setzt sich daher gegen eine allgemeinere durch. Beispiel: write auf Content/** und none auf Content/Secret/** ergibt Schreibzugriff überall in Content/ außer in Secret/.

Automatische Gruppierung Wenn Sie alle Unterelemente eines Ordners markieren, fasst der Client sie zu einer einzigen Regel Parent/** zusammen (die auch künftige Unterordner abdeckt) und entfernt die überflüssig gewordenen Unterregeln.

Standardauflösung

Wenn keine explizite Regel einen Pfad abdeckt, folgt der effektive Zugriff diesem Modell:

Standardmäßig ist der Zugriff read (Lesen), wenn keine Regel zutrifft.
admin und lead haben überall write (Rollen-Bypass).
Ein project_admin hat write auf den von ihm verwalteten Repositories und sonst nichts Besonderes.
Andernfalls gilt die spezifischste Regel; fehlt sie, das standardmäßige Lesen.

Mit anderen Worten: Um jemandem das Lesen eines Ordners zu verbieten, genügt es nicht, nichts zu gewähren (der Standard ist read), es braucht eine explizite none-Regel.

Eine Berechtigung testen

Das Panel Test Permission mit einem Ergebnis, das die effektive Stufe sowie die entscheidende Quelle und das Muster zeigt.

Das Panel Test Permission beantwortet "welchen effektiven Zugriff hat dieser Benutzer auf diesen Pfad?". Wählen Sie einen Benutzer, geben Sie einen Pfad ein (z. B. /Content/Maps/Level01.umap) und starten Sie den Test. Das Ergebnis zeigt die effektive Stufe sowie die Quelle und das Muster, die entschieden haben, sodass Sie verstehen, warum ein Zugriff gewährt oder verweigert wird.

Für einen Benutzer, den Sie nicht sehen dürfen, gibt der Test dasselbe "nicht gefunden" zurück wie bei einem nicht existierenden Konto, um die Existenz von Konten nicht preiszugeben.

Häufige Fallstricke

"Ich habe nichts gewährt, trotzdem kann er lesen"

Das ist der read-Standard. Um einen Ordner zu schließen, setzen Sie eine explizite none-Regel darauf.

Zwei Regeln widersprechen sich

Die spezifischste (größte Tiefe) gewinnt. Verwenden Sie den Test, um zu sehen, welche entscheidet.

Ein Lead bleibt trotz einer none-Regel im Schreibzugriff

Die Rollen admin und lead umgehen die Pfadregeln (überall write). Eine none-Regel schränkt sie nicht ein. Dasselbe gilt für einen project_admin auf seinen eigenen Repositories.

Zugriff über Gruppe vs. direkter Zugriff

Ein Zugriff kann vom Konto selbst oder von einer Gruppe stammen, der es angehört. Wenn das Entfernen einer Regel nichts ändert, suchen Sie die andere Quelle (der Test zeigt, welche gilt).