Direkt zum Seiteninhalt springen
b13 GmbH

Hauptstätter Str. 59
70178 Stuttgart
Germany +49 (0) 711 460 589 70 [email protected]
TYPO3

Redakteursgruppen erstellen, die Kunden lieben

Desirée Lochner
RSS Feed
Zwei Personen interagieren mit einer digitalen Benutzeroberfläche, wobei eine auf einen Bildplatzhalter zeigt, während die andere auf Textfelder deutet. Die Szene zeichnet sich durch ein modernes Design mit lebendigen Farben und abstrakten Formen im Hintergrund aus.

Wie wir uns das „Warum kann der Redakteur das und ich nicht?“-Chaos, Zeit und zusätzliche Arbeit sparen

Der Erfolg eines TYPO3-Projekts hängt maßgeblich mit der Zufriedenheit der Redakteure zusammen, die die Installation regelmäßig nutzen.
Gut durchdachte Redakteursgruppen und ein gut strukturiertes Backend bilden die Basis dafür, dass Redakteure gerne in dem Backend arbeiten (und u.a. auch zufrieden mit Eurer Arbeit sind!).

Eine sinnvoll konzipierte Redakteursgruppen-Logik ist deshalb essentiell für ein System, das auch langfristig gut nutzbar, nachvollziehbar, erweiterbar und wartbar ist. Denn keiner will in einem laufenden Projekt später die Arbeit haben, das Chaos im Backend aufräumen zu müssen.
Wer es gleich richtig macht, spart sich Zeit und Nerven!

In diesem Blogpost zeige ich einige Grundsätze, wie Backend Usergruppen aufgebaut werden können und ein Backend ermöglichen, das Redakteure lieben.

Grundsätze

1. Vom Allgemeinen zum Spezifischen

Beim Aufbau einer Redakteursgruppen-Logik gilt: Immer vom Allgemeinen zum Spezifischen.
Der Fall könnte später eintreten, dass eine Redakteursgruppe benötigt wird, die einen sehr eingeschränkten Zugriff haben soll (z.B. nur ein bestimmtes Modul, in dem nur ein bestimmtes Contentelement gepflegt werden darf). 
Aus diesem Grund braucht es eine Basis, auf der diese spezifische Redakteursgruppe aufgebaut werden kann (siehe Abschnitt zu „Basic Page Access“).

2. „Verkonfiguriere“ nicht deine Backend-Benutzer: Eine neue Redakteursgruppe tut keinem weh

Besonders in Installationen mit sehr vielen Backend Users ist es nicht empfehlenswert, spezifische Konfigurationen an einem Backend User vorzunehmen, um seinen Zugriff zu beschränken oder zu erweitern (z.B. wenn ein Redakteur aus einer Abteilung spezifische Rechte bekommt).
Es ist immer besser, für solche Fälle eine auf den Nutzer oder das Team zugeschnittene Redakteursgruppe zu erstellen. Alle zukünftigen Änderungen können dann an der Gruppe vorgenommen werden, ohne dass die Nutzer im Einzelnen angepasst werden müssen.

Kommen nämlich neue Redakteure zum Team dazu, die dieselben Berechtigungen benötigen, müsste man zu jeder Zeit noch wissen, welche Nutzer im selben Team sind und dieselben Zugriffsrechte haben.
Und mal ganz ehrlich: Dein Kopf hat wichtigere Dinge zu tun als sich das zu merken!

Also: Mach dir dein Leben einfacher! Erstelle einfach neue Backend Usergruppen.

3. Nutze das Beschreibungsfeld unter „Hinweise“

Hinterlasse eine Beschreibung an der Nutzergruppe, die genau erklärt, wofür eine Nutzergruppe gedacht ist (und wozu auch nicht). Das wird dein Leben (und das der anderen) deutlich erleichtern, wenn Du nach Monaten oder Jahren Anpassungen an der Konfiguration vornehmen sollst.
Zusätzlich bewahrt es andere auch davor, unabsichtlich Konfigurationen vorzunehmen, die die grundsätzliche Logik „zerstören“.

Bearbeitungsoberfläche für die Benutzergruppe „Standard-Editor“ im Backend, die Abschnitte für Dateninformationen, Beschreibung, Zugriffsrechte und Optionen anzeigt. In der Beschreibung wird sie als Basisbenutzergruppe zur Verwaltung spezifischer Zugriffsrechte bezeichnet.

4. Zugriff auf die Filelist/einen spezifischen Filemount

Vergiss nicht, dass Deine Redakteure Dateien hochladen, verwenden und verwalten möchten. 
Lege deshalb — nach Bedarf — entsprechende Filemounts an und weise diese deiner Backend User-Gruppe zu (lieber der Gruppe als einem User — siehe Punkt 2).

5. Nicht verwendete Datenbank-Felder können komplett entfernt werden

Damit die Einrichtung der Usergruppen so einfach wie möglich geht, sollten alle nicht genutzten Datenbank-Felder mit Hilfe der TCA Konfiguration oder PageTSconfig aus der Installation entfernt werden. Das sollte im besten Fall direkt bei der Integration eines neuen Contenttyps oder Plugins geschehen, da der Entwickler zu diesem Zeitpunkt am besten weiß, welche Felder tatsächlich genutzt werden.

Bei der Konfiguration muss dann keiner überlegen, welche Felder den Nutzergruppen zugeordnet werden müssen und welche nicht.

Notiz am Rande: Es gibt zwei Wege, um Datenbankfelder zu konfigurieren: „explicitlyAllow„ (explizit erlauben) und “explicitlyDeny„ (explizit verbieten).
Um ein komplexes System erweiterbar zu halten, sollte immer die „explicitlyAllow„-Option verwendet werden. So kann vermieden werden, dass Felder verboten werden, die eigentlich aufgrund der Vererbung innerhalb einer Eltern-Nutzergruppe bereits erlaubt wurden.

Ein- und Ausblenden von einzelnen Feldern in Seiten, Contenttypen oder anderen Datensatztypen auf Basis von Usergruppen sollte nur dann vorgenommen werden, wenn eine allgemeine Behandlung nicht möglich oder sinnvoll ist, d.h. wenn es also tatsächlich für das gleiche Element unterschiedliche Berechtigungen geben muss. 

Ein mögliches Beispiel ist die Checkbox „Restrict editing to admin users“ in Contentelementen, die für Redakteure weder sicht- noch editierbar sein sollte. Wird die Checkbox nämlich aktiviert, schließt sich der Redakteur selbst von der Bearbeitung des Elements aus. Diese Möglichkeit sollte er erst gar nicht haben ;-).

6. Datenbank-Felder müssen sinnvoll benannt werden

Um es möglichst übersichtlich und nachvollziehbar zu machen, sollten die einzelnen Datenbankfelder sinnvoll und verständlich benannt werden (im Default TCA). Die Bezeichnungen sollten für alle am Projekt Beteiligten (z.B. Projektmanager) verstanden werden können — nicht nur von Entwicklern.

7. Installation der benötigten Sprache

Viele Redakteure möchten das Backend am liebsten in ihrer Muttersprache bedienen und nicht auf Englisch.
Vergiss deshalb nicht,  das entsprechende Sprachen-Paket in TYPO3 zu installieren, damit das Backend auch in der gewünschten Sprache verfügbar ist.

8. Vergiss die Konfiguration über das Access-Modul nicht

Über das Access-Modul wird gesteuert, welche Berechtigungen auf Seitenebene für die Redakteursgruppen gelten. Hierbei wird zwischen der „Group“ und „Everybody“ unterschieden.

Für die Konfiguration von „Everybody“ muss der kleinste gemeinsame Nenner aller Redakteursgruppen identifiziert werden.

Beispiel: Alle Redakteure dürfen Seiten sehen und Content bearbeiten, manche aber auch zusätzlich noch Seiteneigenschaften pflegen. In diesem Fall wäre der kleinste gemeinsame Nenner aller Redakteursgruppen demnach „Show Page“ und „Edit Content“, da ja nicht alle Redakteure Seiteneigenschaften bearbeiten dürfen (d.h. „Everybody“ bekommt diese beiden Berechtigungen). Die zusätzliche Berechtigung für Seiteneigenschaften muss dann über die Konfiguration „Group“ gesteuert werden.

9. Halte fest, wie die Backend Usergruppen konzipiert sind

Besonders in komplexen Installationen empfehlen wir, die Logik der Backend Usergruppen zu dokumentieren, damit alle Beteiligten die Logik jederzeit einsehen und verstehen können.

Ein einfaches Diagramm, auf das alle Beteiligten Zugriff haben und ggf. Angepasst werden kann, ist dafür sehr hilfreich.
 

Flussdiagramm, das die Benutzerzugriffslevel für ein System darstellt. Es umfasst „Basisseitenzugriff“, „Standard-Editoren“ und spezifische Benutzergruppen für Personalwesen, Marketing und Produktmanagement, wobei deren Rollen und Zugriffsberechtigungen detailliert beschrieben werden.

Wie sollte ich die Usergruppen-Logik aufbauen?

Die Redakteursgruppen-Logik kann wie ein Haus betrachtet werden: Die Gruppen basieren jeweils auf einer anderen Gruppe und werden so mit jedem Stockwerk immer spezifischer.

Diagramm, das eine hierarchische Struktur veranschaulicht, mit einem zentralen Haus, das "Standard-Redakteur" repräsentiert, und vier Abteilungen, die von "Redaktion Abteilung 1" bis "Redaktion Abteilung 4" beschriftet sind. Ein kleineres Haus mit der Bezeichnung "Basis-Gruppe

Hinweis:

Diese Logik ist ein Vorschlag, der für wenig komplexe Berechtigungslogiken für die meisten Projekte funktionieren sollte. In Ausnahmefällen (d.h. bei sehr komplexen Redakteurskonzepten) kann die Logik abweichen.

1. Basis-Gruppe [= „Basic Page Access“] - das Fundament der Redakteursgruppen

  1. Zu Beginn eines Projekts sollte bereits die erste Redakteursgruppe „Basic Page Access“ angelegt werden, die die Basis für alle weiteren Redakteursgruppen bildet.
  2. Diese wird in der TYPO3-Konfiguration (TCEMAIN.permissions) so hinterlegt, dass (i.d.R.) alle Seiten diese Gruppe erhalten (kann im Access-Modul eingesehen werden).
    Hinweis: Es gibt selbstverständlich Sonderfälle und Anforderungen, in denen die Basic Page Access nicht als Basis für alle anderen dienen kann.
  3. Wichtig: Die Basic Page Access-Gruppe erhält sonst keinerlei weitere Berechtigungen innerhalb der Usergroup!
    Diese Gruppe dient dazu, dass neu angelegte Seiten (egal von welchem Redakteur mit welcher Redakteursgruppe) grundsätzlich sichtbar sind für andere Redakteure (und nicht wie es sonst TYPO3-Standard wäre nur für die Personen mit derselben Redakteursgruppe wie die des Seiten-Erstellers).
Tabelle mit Berechtigungen, die Spalten für "Besitzer," "Gruppe," "Jeder" und "Sperren" enthält. Die Zeile zeigt die Berechtigungen für die "Startseite" mit Häkchen und einem roten Kreuz für verschiedene Zugriffslevel an.

2. Standard-Redakteursgruppe — das Erdgeschoss

  1. Die Standard-Redakteursgruppe erbt die Einstellungen der Gruppe „Basic Page Access“.
  2. Die Standard-Redakteursgruppe stellt die Konfiguration für den „Standard“-Redakteur dar. Hier werden also alle Einstellungen vorgenommen, die für die meisten Redakteure benötigt werden, d.h. Alle Contenttypen, Module, Plugins, die alle Redakteure sehen und bearbeiten können sollen.
    Ausgenommen sind hier Redakteure mit sehr eingeschränktem Zugriff (siehe Punkt 4 dazu).
Backend-Benutzergruppeneinstellungen für "Standard-Redakteur" mit Abschnitten für Bearbeitungsberechtigungen, Datenbankeinträge und verfügbare Objekte. Die Benutzeroberfläche umfasst Felder zur Eingabe von Daten und zur Verwaltung der Verfügbarkeit von Objekten.

3. Redakteure mit spezifischen Zugriffsrechten (z.B. Redakteure einer bestimmten Abteilung) – die Zimmer im Obergeschoss

  1. In den meisten Projekten haben wir Backend Nutzer aus verschiedenen Unternehmens-Abteilungen, die deshalb auch häufig nur Zugriff auf einen bestimmten Teil des Seitenbaums erhalten (z.B. nur die Karriere-Seiten für die HR-Abteilung o.Ä.).
  2. Diese Redakteure erben also die Einstellungen der Standard-Redakteursgruppe (welche die Einstellungen der Basic Page Access-Gruppe erbt) und erhalten zusätzlich nur spezifische Berechtigungen auf einen Teil des Seitenbaums und einen bestimmten Filemount.
Benutzeroberfläche zur Bearbeitung der Backend-Benutzergruppe "Editor Human Resources", die Abschnitte für Datenberechtigungen, Auswahlmöglichkeiten und verfügbare Objekte anzeigt. Die Felder umfassen "Karriere" sowie Optionen zur Verwaltung des Benutzerzugriffs und der Berechtigungen.

4. Redakteursgruppe mit sehr eingeschränkten Berechtigungen — die Hundehütte

  1. Damit auch im Nachhinein noch Redakteursgruppen erstellt werden können, die sehr spezifische und wesentlich geringere Zugriffsrechte haben als die Standard-Redakteursgruppe (z.B. Zugriff auf nur ein bestimmtes Modul oder aber nur Zugriff auf ein paar spezifische Contentelementtypen etc.), dürfen der Basic Page Access-Gruppe keinerlei weitere Rechte gegeben werden 
    Auch wenn es momentan evtl. so aussieht, dass es „ohnehin nur eine Redakteursgruppe gibt, bei der alle dasselbe können“, wird es später sicherlich einen Sonderfall geben. Den gibt es nämlich immer. Wirklich immer ;-).
  2. Die „Hundehütte“ erbt damit die Konfiguration der Basic Page Access-Gruppe.

Das Wichtigste kurz und knapp

  • Backend Nutzergruppen sollten sauber konzipiert werden, BEVOR sie konfiguriert werden. Sprich dazu immer mit dem Kunden, damit seine Bedürfnisse und Strukturen in den Gruppen gut abgebildet werden. Wird das berücksichtigt, muss nachher keiner das Chaos beseitigen.
  • Nutzergruppen sollten immer vom Allgemeinen zum Spezifischen aufgebaut werden.
  • Entwickler sind keine Redakteure. Trotzdem müssen sie das Backend durch die Augen eines Redakteurs betrachten, wenn sie es konfigurieren.
  • Glaube niemals der Aussage „Wir brauchen wirklich nur eine Nutzergruppe für alle Redakteure. Da gibt es keine Ausnahmen.“ Das stimmt nicht. Nie.
  • Ein gut durchdachtes System spart dir, deinen Kollegen und dem Kunden unglaublich viel Zeit (und Nerven).
    Außerdem macht es den Redakteuren in ihrer täglichen Arbeit sehr viel mehr Spaß damit zu arbeiten — und davon profitieren letztlich alle.
    Ich versprech’s.

Geschrieben von:

Lächelnde Frau mit schulterlangem Haar, die ein helles Oberteil trägt, in einem modernen Büroumfeld mit verschwommenem Hintergrund.

Kreative Projektmanagerin die mit Herz und Sachverstand stets die Fäden zusammenhält - im Büro und auf der Bühne

Desirée Lochner Consulting
mehr von Desirée Lochner

Ähnliche Artikel