Redakteursgruppen erstellen, die Kunden lieben

27. März 2020 |Desirée Lochner

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“.

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.

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.

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

Zu Beginn eines Projekts sollte bereits die erste Redakteursgruppe „Basic Page Access“ angelegt werden, die die Basis für alle weiteren Redakteursgruppen bildet.
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.
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).

2. Standard-Redakteursgruppe - das Erdgeschoss

Die Standard-Redakteursgruppe erbt die Einstellungen der Gruppe „Basic Page Access“.
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).

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

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.Ä.).
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.

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

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 ;-).
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.