Rechte zuweisen

Die Rechtedefinitions-Komponente erscheint nach dem Anlegen und der Auswahl in den Projekteigenschaften auf dem Metadaten-Register jedes Objekts. Hier kann der Redakteur Rechte für das jeweilige Objekt vergeben.

Erläuterung der Komponente

1. Initial sind in einem Projekt keine Metadaten für die Rechtedefinitions-Komponente gesetzt. Um eine grundlegende Definition vorzunehmen, sollten die Rechte zunächst für die jeweiligen Wurzelknoten gesetzt werden. Durch Aktivierung der Checkbox können die Rechte für den ausgewählten Knoten in der Baumstruktur (und alle darunter liegenden Knoten) definiert werden.
2. Jede Benutzeraktion, für die Rechte (erlaubt, verboten, geerbt) definiert werden sollen (z. B. „lesen“, „löschen“), befindet sich auf einem eigenen Register.
3. Hier werden die einzelnen Gruppen mit ihren Untergruppen in einer Baumstruktur dargestellt. Vor jeder Gruppe wird durch ein Symbol angezeigt, welches Recht für diese Gruppe gültig ist und wo dieses Recht definiert wurde bzw. ob es sich um ein vererbtes Recht handelt.
4. Hier wird für jede Gruppe das gültige Recht in einer Übersichtsliste angezeigt.

Rechte zuweisen

Folgende Rechte können vergeben werden:

Durch mehrfaches Klicken auf das jeweilige Icon können Rechte geändert werden. Dabei werden gegebenenfalls auch die grauen Symbole im darunter liegenden Teilbaum geändert. Wird z. B. das Recht einer Obergruppe von „Verboten“ (Rotes Kreuz) auf „Erlaubt“ (Grüner Haken) gesetzt, ändert sich das Recht von darunter liegenden Gruppen automatisch von „Verboten“ (Graues Kreuz) in „Erlaubt“ (Grauer Haken). In diesem Zusammenhang wird von einer „Vererbung“ gesprochen, d.h. die Kind-Objekte erben die Eigenschaften von einem Vater-Objekt.

Wurden für einen ausgewählten Knoten keine Rechte definiert, jedoch für einen darüber liegenden, so wird die Definition des Knotens angezeigt, auf dem die Rechte definiert wurden. Erkennbar ist dies daran, dass hinter dem Namen des ausgewählten Knotens in der Baumstruktur des SiteArchitects kein entsprechendes Symbol zu sehen ist (wenn keine anderen Metadaten definiert wurden, Metadaten werden durch das Icon in der Baumstruktur visualisiert, falls entsprechend konfiguriert) und der Haken bei „Rechte Definieren“ in der Rechtedefinitions-Komponente fehlt.

Werden neue Gruppen angelegt, erhalten sie automatisch das Recht der übergeordneten Gruppe. Für neue Gruppen auf oberster Ebene hinzukommen gilt standardmäßig das Recht „Verboten“.

Vererbung

Neben der Gruppenhierarchie existiert bei den Benutzerrechten zusätzlich ein Bezug zur Baumstruktur der FirstSpirit Verwaltungen, die ebenfalls als Hierarchie interpretiert wird. Analog zur Vererbung von Redaktionsrechten gelten auch die Benutzerrechte immer für das Objekt im Baum, für das sie definiert wurden und werden an alle Objekte vererbt, die diesem Objekt innerhalb der Baumstruktur untergeordnet sind. Das bedeutet: Wenn in einem Baum-Objekt keine Benutzerrechte definiert sind, so gelten die Rechte des Vater-Objektes. Durch diese Vererbungsdefinition ist es einfach möglich, z. B. auf der Ebene eines Ordners Rechte für alle darunter liegenden Seiten zu definieren.

Die Vererbung ist als „nicht additiv“ definiert – das bedeutet, dass eine Rechte-Definition in einem Objekt alle „darüber liegenden“ Definitionen überschreibt.

Widersprüche und Probleme bei der Konfiguration

Wenn Rechte explizit auf einem Knoten definiert werden, kann es bei hierarchischen Strukturen zu Widersprüchen kommen. Wird beispielsweise der Zugriff einer Gruppe für einen Ordner der Struktur-Verwaltung explizit verboten, der Zugriff für einen untergeordneten Ordner jedoch explizit erlaubt, so stehen diese definierten Rechte im Widerspruch zueinander. Die Plausibilität der Rechtevergabe wird über die Eingabekomponente nicht geprüft.

Um Widersprüche zu vermeiden, sollte beispielsweise bei der Rechtedefinition innerhalb der Struktur-Verwaltung die Menge der berechtigten Gruppen entlang des Baumes nur eingeschränkt, aber nie erweitert werden, da in diesem Fall der Zugriff auf ein „tieferes Element im Baum“ nur über den „darüber liegenden Knoten“ erfolgen kann. Damit ist eine Erweiterung der Berechtigungen sinnlos, da der darüber liegende Einstiegspunkt fehlt.

Bei Widersprüchen kann in der Eingabekomponente mit dem Parameter priority priorisiert werden, welches Recht (also entweder „Erlaubt“ oder „Verboten“) bevorzugt werden soll.

Beispiel: Wird auf dem Wurzelknoten der Struktur-Verwaltung das Recht „Lesen“ für „Group 1“ explizit verboten, so kann es für diese Gruppe im untergeordneten Ordner „Company“ nicht explizit erlaubt werden. Diese Rechtevergabe steht im Widerspruch zur Rechtedefinition des Vaterknotens. Der gleiche Widerspruch wirkt sich auch auf die ererbten Rechte von „Group 1.2“ aus. Anders sieht das Verhalten für „Group 1.1“ aus: Diese erhält im Wurzelknoten explizit das Recht „Lesen“ und kann dieses Recht auch im untergeordneten Ordner „Company“ beibehalten. Eine Einschränkung der Rechte im untergeordneten Element, wie bei „Group 2“, ist natürlich jederzeit möglich.