Anlegen, Editieren und Löschen in einem geschützten Frontend-Bereich

Programmcode

Seit einem Jahr arbeiten wir für 12bis3 am Relaunch eines großen Projektes, dessen Hauptaugenmerk im Anlegen, Editieren und Löschen in einem geschützten Frontend-Bereich liegt.

Vom Beginn dieses Projektes an, kam immer wieder die Frage nach einem Logging der Änderungen im Frontend auf, ähnlich wie das TYPO3-Backend dies schon tut.

Aufgrund der immer größer werdenden Anforderungen und der regelmäßigen Rückfragen der Benutzer an unseren Kunden, wann welche Änderungen denn gemacht worden sind, wurde die Notwendigkeit immer größer.

Ich habe mir die Mühe gemacht und das System Logging des TYPO3-Backends angeschaut, um herauszufinden, wie es funktioniert, wo man angreifen kann und was man alles benötigt, um die Daten sauber ins System Logging einzutragen.

Aufgrund der Komplexität der sys_log-Tabelle habe ich diese außen vor gelassen, und mich der einfacheren, aber für die Aufgabe wichtigeren sys_history zugewandt. Ich habe analysiert, wie der DataHandler die Daten in die Tabelle bekommt. Eine Abhängigkeit zur sys_log, wie im alten TYPO3 besteht nicht mehr, wodurch es einfacher wird, die Daten zu erfassen.

Glücklicherweise gibt es im RecordHistoryStore in TYPO3 bereits Vorbereitungen, zu erfassen, welcher Usertyp Änderungen vorgenommen hat, und dies habe ich genutzt. Ich habe den RecordHistoryStore ergänzt und einen eigenen gebaut, welcher die benötigten Funktionen create, update und delete erfasst und entsprechend ins Log eintragen kann.

Auf die Funktionen des Verschiebens habe ich verzichtet, da das Frontend im Normalfall dafür nicht vorgesehen ist, Datensätze in andere Ordner zu bewegen. Der einzige mir bekannte Anwendungsfall ist das Verschieben eines Datensatzes in ein Archiv.

Für die Anzeige im Backend fiel mir dann auf, dass die Änderungen jetzt zwar sauber erfasst, aber die User-Informationen nicht ausgegeben werden. Nach einer Analyse fand ich den entsprechenden Controller, habe ihn überladen und die entsprechende Stelle angepasst. Ganz geschickt ist das nicht, aber eine entsprechende Middleware oder ein SignalSlot, um nur die spezifischen Teile anzupassen, gibt es an dieser Stelle leider nicht.

Die ersten Versuche machte ich mit einem Trait, welcher in den Controller eingebunden werden kann und die benötigten Funktionen beinhaltet. Die zu große Komplexität und das eventuelle Vergessen, an jeder Stelle die Aufrufe einzubinden, sorgte dafür, dass ich diese Idee schnell wieder verwarf. Der Trait selbst ist aber noch da und kann in dieser Form an anderen Stellen, falls benötigt eingebunden werden. Sollte jemand dafür Verwendung haben, werde ich ihn in der Extension belassen, ansonsten werde ich das System einem Refactoring unterziehen und den Code hier vereinfachen.

Um eine halbwegs saubere MVC-Struktur zu erhalten, kam mir der Gedanke, dass das Model nach Möglichkeit selbst wissen soll, wann es geändert werden muss.

Mit einigem Code Insight und der Unterstützung von Frank habe ich die Option genutzt, dass jedes Objekt persistiert wird. Der PersistenceManager von Extbase hat für jeden Vorgang auch die passenden SignalSlots. Dies zapfe ich an und schaue in das Objekt rein, was passiert ist. Passend dazu wird dann der HistoryRecord erstellt. Damit der PeristenceManager aber erkennt, dass es sich hier um ein Model handelt, welches einen History-Eintrag bekommen soll, habe ich ein leeres Interface erstellt, welches als Kennung verwendet wird. Durch die Registrierung als Objekt dieses Interface erkennt der SignalSlot, dass ein Eintrag erzeugt werden muss und holt aus allen Properties die geänderten und die passenden originalen Einträge und trägt sie systemkonform in die Datenbank ein.

Nach anfänglich erfolgreichen Tests innerhalb des Kundenprojektes habe ich mich entschlossen, diese Extension aus dem System zu lösen und eigenständig zu stellen, da die entsprechenden Anforderungen sehr wahrscheinlich häufiger auftreten und alleine unser Portfolio schon genug bietet, bei dem man diese Funktionen gebrauchen kann.

Wie benutzt man diese Extension?

Entweder der Download erfolgt über das TYPO3 Extension Repository (https://extensions.typo3.org/extension/fe_data_history), oder aber eine Installation erfolgt via composer.

composer require sudhaus7/fe-data-history

Um ein im Frontend editierbares Model als logbar zu kennzeichnen, muss nur das oben erwähnte Interface im Model eingebunden werden. Danach werden die Änderungen im Backend per History/Undo sichtbar und können auch rückgängig gemacht werden.

class MyLoggableModel extends AbstractEntity implements HistoryEntityInterface

Ein Backport auf Version 8 wurde geplant, aber aufgrund der komplexen Abhängigkeit der sys_history an das sys_log und den bald ablaufenden LTS wurde die Idee wieder verworfen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.