Die letzten Schritte bei unserer Arbeit, die "FC Bigfeet" Site zum Laufen zu bringen, ist ein Blick auf die verteilte Pflege - eine grundlegende Voraussetzung an ein CMS.

Wir haben bereits über den Unterschied zwischen Frontend- und Backend-Benutzern gesprochen und wissen, dass Backend-Benutzer in der Wurzel des Page Trees angesiedelt sind:

Drei Benutzer gibt es bereits. Überprüfen Sie, was diese anstellen können. Der beste Weg dazu ist es sich als Administrator abzumelden und als einer der Benutzer anzumelden, einer nach dem anderen. Alle Passwörter lauten bisher "football".

"christine"

Wenn Sie sich als "christine" anmelden, werden Sie folgendes sehen, wenn Sie das Page Modul zu Bearbeitung aufrufen:

Nur eine Seite!! Richtig, "christine" darf nur eine einzige Seite bearbeiten, nämlich die "This week"-Seite. Das ist ihre Aufgabe. Wir wollen nicht, dass sie irgendwo anders herumwurstelt - nur diese Seite.

Das ist ziemlich klasse - sie bekommt nur die Seite zu sehen, die sie auch sehen muss. Es spiegelt also nicht nur die Rechteverwaltung wider sondern trägt auch dazu bei, dass das System intuitiver und benutzerfreundlicher wird. Wie Sie sehen, sind viele der Backend Module ebenfalls verschwunden. Auf der linken Seite finden Sie lediglich das "Page" und das "View" Modul, zusätzlich zum "Help"-Hauptmodul, das keine besonderen Rechte erfordert.

"jonathan"

Nun melden wir uns als "jonathan" an:

Jonathan ist der Trainer der Jugendgruppe des Clubs. Er ist also verantwortlich für alle Seiten, die damit zu tun haben! Genauso wie Christine kann auch er nur die Dinge sehen, die er auch wirklich sehen soll.

Im Gegensatz zu Christine wurden ihm zusätzlich die Rechte für das Filelist Modul gewährt: Wenn Sie allerdings nachsehen, was darin ist, werden Sie einen kleinen Unterschied zu der Ansicht des Administrators sehen:

Das Stammverzeichnis ist nicht "fileadmin/" sonder direkt der Ordner des Bilderarchivs"

Jetzt wollen wir aber wissen, wie die Benutzer "jonathan" und "christine" eingerichtet wurden! Wie hat er das gemacht, der Typ, der hinter all dem steckt? Nun, melden wir uns einfach als "admin" an und finden es heraus!

Wählen Sie zunächst die Option "Edit" für die beiden Benutzer "jonathan" und "christine". Sie werden sehen, dass ihre Profile in zwei Punkten "identisch" sind: Sie haben die gleiche Gruppenzugehörigkeit (#1) und sie beide haben einen "DB mount" (#2, das ist der Startpunkt für ihre individuellen Page Trees). Aber Jonathan darf zusätzlich das "file" und das "file_list" Modul benutzen (#3) und außerdem wurde ihm ein File Mount "Image Archive" eingerichtet (#4). Das macht Sinn, denn schließlich ist es das, was wir gesehen haben, als wir unter seinem Namen angemeldet waren.

File Mounts

Der File Mount, der "jonathan" zugewiesen wurde, ist eine Beziehung zu einem einfachen Datensatz, der ebenfalls in der Wurzel des Page Trees angelegt wurde:

Wenn Sie diesen zum Bearbeiten öffnen, werden Sie sehen, wie logisch er aufgebaut ist:

Das Verzeichnis "Image_Archive/" (#1) wurde als Pfad angegeben und das "BASE"-Feld wurde so konfiguriert, dass der Pfad relativ zum "fileadmin/"-Verzeichnis betrachtet wird (#2). So einfach ist das. Solange Jonathan eine Beziehung zu diesem Eintrag gesetzt hat, wird dieses Verzeichnis direkt in sein Filelist Modul gemountet!

DB mounts

Die DB mounts (database mounts) sind sehr einfach zu verstehen - grundsätzlich zeigen sie auf eine Seite innerhalb des Page Trees, welche der Start für den Page Tree werden soll, die der Benutzer sehen darf! Es könnte also kaum einfacher sein, einem Benutzer Zugriff auf einen bestimmten Teil des Page Trees zu gewähren - wählen Sie einfach die entsprechende Seite. Oder sogar zwei! Sie können beliebig viele "DB mounts" verwenden!

Seiten Berechtigungen

Ach ja. Noch eine Bemerkung zu den "DB mounts" - wenn der Benutzer keinen Lesezugrif auf die Seite und den Unterseiten des DB mounts hat, ist es vollkommen egal, was Sie sonst noch konfiguriert habe - es wird nicht funktionieren! Und was bedeutet das - Lesezugriff? Nun, jede Seite hat Rechte-Einstellungen so wie das Dateisystem auf einem UNIX-Server - es gibt einen Besitzer, eine Besitzer-Gruppe und schließlich Zugriffseinstellung in fünf verschiedenen Kategorien: Seiten lesen, bearbeiten, löschen, neue Unterseiten und Seiteninhalte erzeugen. Normalerweise sind die Standardeinstellungen gut genug, und es ist vermutlich der einfachste Weg, wenn man dabei die DB mounts als Zugriffsverwaltung verwendet. Wenn Sie Probleme bekommen, setzen Sie die Berechtigungen einfach auf "an" - das wird eine Reihe von Sternen in der gesamten Zeile erzeugen (siehe Bild unten). Und wenn Sie mehr darüber erfahren wollen, sollten Sie sich das Dokument Inside TYPO3 ansehen - dort finden Sie die haarsträubende Erklärung.

Der vermutlich beste Weg um Ihnen zu zeigen wie Seitenberechtigungen gesetzt werden sollen, ist Ihnen die aktuellen Berechtigungen des Page Trees zu zeigen. Das machen wir mit dem "Access" Modul:

Wenn Sie sich die Besitzerverhältnisse der Seiten ansehen, werden Sie feststellen, dass "jonathan" für einige Seiten als Besitzer eingetragen ist. Er mag vielleicht sogar der Ersteller dieser Seiten sein. Wenn Sie eine neue Seite erzeugen, werden Sie automatisch ihr Besitzer.

Aber der wichtigste Punkt ist, dass die Gruppe "GENERAL" die Besitzer-Gruppe der Seiten ist, auf die Jonathan und Christine beide Zugriff benötigen. Und da sie beide Mitglieder dieser Gruppe sind, haben sie beide Zugriff auf diese Seiten (allerdings werden sie immer nur im Bereich ihres DB mounts arbeiten können!). Das einzige was sie nicht tun können - zumindest "christine", weil sie die "This week" Seite nicht besitzt - ist eine Seite löschen die Teil der GENERAL Gruppe ist. Das können Sie sehen, wenn Sie auf einen der Bleistifte klicken:

Wie Sie sehen wurde das Recht für "Delete page" hier für die Gruppe nicht gesetzt. Das können Sie natürlich ändern, wenn Sie möchten, dass Christine sie löschen kann - aber anscheinend soll sie das nicht. Tatsächlich könnten Sie ihre Rechte noch weiter einschränken, indem Sie ihr nicht erlauben, neue Unterseiten zu erstellen oder den Seitentitel zu verändern:

Das Ergebnis sehen Sie in der Rechte-Übersicht:

Überprüfen der Einstellungen

Mit dem Modul "User Admin" können Sie überprüfen, ob "christine" nun die korrekten Zugriffsrechte auf diese Seite besitzt:

Das wird Ihnen sofort zeigen, welche kombinierten Rechte sie hat:

Die ersten beiden grünen Sterne bedeuten "Seite lesen" und "Neuer Inhalt auf dieser Seite" - die roten Kreuze bedeutet "Darf weder bearbeiten, löschen noch neue Seiten erstellen"

Riskieren wir einen Blick auf dieselbe Ansicht für Jonathan:

Das zeigt uns klar, was wir erwarten würden - der File Mount und die Web Mounts sind so, wie wir sie schon vorher gesehen haben. Jonathan kann ausserdem nicht die Hauptseite "Youth Section" löschen.

Das User Admin Modul ist ein sehr hilfreiches Tool um Benutzer Einstellungen zu überprüfen, Benutzer zu vergleichen usw. Unersetzlich ist es, wenn Sie viele Benutzer haben und einen Überblick über ihre Rechte behalten wollen!

Schauen wir uns die GENERAL-Gruppe an, in der "jonathan" und "christine" beide Mitglieder sind:

Die "Include Access Lists" ist ein wichtiger Punkt, denn es ist der Grund, warum all diese Optionen überhaupt angezeigt werden! Unabhängig davon kann die Gruppe ebenfalls DB mounts und File mounts enthalten, die an alle Benutzer weitergegeben werden, die in dieser Gruppe Mitglied sind.

Modules

Wenn Sie sich die Access Lists ansehen (#1) sehen Sie, dass die Mitgliedschaft in dieser Gruppe den Zugriff auf das Web-, Page- und List-Modul erlauben wird (dummerweise müssen Sie dazu wissen, dass diese Kürzel immer den Namen die Sie aus dem Menü kennen, entsprechen...).

Tables (modify)

Hier finden Sie die Tabellen, die "jonathan" und "christine " bearbeiten dürfen (#2). Kann das denn stimmen? Können sie wirklich nur die Page und Pagecontent Tabelle sehen? Nun, lassen Sie es uns ausprobieren und uns als "jonathan" anmelden um ein neues Element zu erzeugen:

Das ist interessant - nur Seiten und Seiteninhalte können erzeugt werden. Keine Benutzer, Gästebucheinträge, keine News. Nur Seiten und Seiteninhalte.

Warum das? Nun, weil Jonathan sich mit nichts mehr beschäftigen soll als mit seinen Dingen! Schließlich ist er nicht derjenige, der für die News zuständig ist, richtig?

Page types

Dieses Feld (#3) legt fest, welche Seitentypen Jonathan und Christine - oder Mitglieder der Gruppe GENERAL - auswählen dürfen. Lassen Sie uns noch einen "Jonathan-Test" machen und einen Page Header bearbeiten:

Mit Jonathans Anmeldung versuchen wir einen sysFolder zu erstellen. Werden wir Erfolg haben?

Leider nicht. Sorry, Jonathan. Das geht hier nicht.

Allowed Excludefields

Das ist eine laaaaaaange Liste. Aber wichtig. Und mächtig! Aber man benötigt etwas Hintergrundwissen dafür:

Wenn Tabellen und Felder in TYPO3 konfiguriert werden (in dem internen globalen PHP Array - $TCA) werden manche Felder als "excludeFields" markiert. Das bedeutet, dass diese Felder nicht bearbeitet werden dürfen, es sei denn, man hat eine besondere Erlaubnis dazu - und das ist genau das, was man in den "Allowed Excludefields" festlegt!

Es ist einfach zu verstehen, wenn Sie sich anschauen, was "jonathan" sieht, wenn er einen Page Header bearbeitet:

Nicht gerade eine beeindruckende Anzahl an Feldern. Vor allem nicht, wenn Sie das mit dem vergleichen was Sie sehen - als Administrator:

Der Grund für diesen Unterschied ist, dass

Record locking?

Vielleicht haben Sie während Sie sich ab- und wieder angemeldet haben bemerkt, dass das folgende Symbol erscheinen kann:

Dies warnt die Benutzer davor, dass gerade jemand anderes an dieser Seite arbeitet - in TYPO3 werden Datensätze nicht wirklich blockiert, denn die Leute sollen Zugriff auf die Seite haben, wenn sie dies dürfen. Aber diese Warnung ist ein nettes Gimmick, weil sie den Leuten hilft, Konflikte zu vermeiden.

Nun, mit all unserem brillanten Wissen können wir nun einen Benutzer erstellen, der mit der zweiten Website betraut wird - der Fan Club Site.

1. Schritt: Den Benutzer anlegen

Benutzer sind lediglich Datensätze - erzeugen Sie einen "Backend User"-Datensatz:

Geben Sie den Benutzernamen, das Passwort (football), die Gruppenmitgliedschaften und den DB mount an:

Speichern Sie "phil" ab.

2. Schritt: Den neuen Benutzer testen

Überprüfen Sie im User Admin Modul, dass "phil" den korrekten Zugriff auf die "Fan Club"-Site hat:

Ooops - typischer Fehler. Wir haben vergessen, die Zugriffsrechte für die Seiten einzustellen! Aber das ist schnell getan - gehen Sie in das Access Modul:

3. Schritt: Die richtigen Seiten-Rechte setzen

Bearbeiten Sie die Rechte für die Root-Seite der Site:

Anschließend legen Sie den Besitzer und die Gruppe fest und stellen sicher, dass die Einstellung "rekursiv" ausgewählt wurde - das sorgt dafür, dass die Änderungen für alle Unterseiten bis zu 1 Ebene wirksam werden:

Hübsch:

4. Schritt: Der letzte Check

Im "User Admin"-Modul sehen die Einstellungen für "phil" nun schon viel besser aus:

5. Schritt: Den neuen Benutzer testen

Zu guter Letzt melden Sie sich als "phil" an. Ein netter Trick ist, einfach den "SU"-Button (Switch User) im User Admin Modul zu klicken - dadurch werden Sie als der entsprechende Benutzer angemeldet, ohne das Passwort einzugeben (das funktioniert natürlich nur bei "admin"-Benutzern...):

Und für "phil" sieht es wirklich gut aus - er hat Zugriff auf alle Seiten der neuen Website!

So einfach ist das.