Audit Log Änderungsprotokoll | Admin Protokoll macht Änderungen sichtbar

Auf einen Blick

• Du siehst sofort, wer wann was im Backend geändert hat
• Vorher und Nachher je Feld: falsche Preise sind schnell zurückverfolgt
• Einträge lassen sich über Admin und API weder ändern noch löschen
• Datenschutz ab Werk: IP aus, Passwörter geschützt, Frist mit Auto-Löschung
• Speichern im Backend wartet nicht aufs Protokoll, es läuft im Hintergrund

Montagmorgen, der Bestseller steht auf 9,90 € statt 99,00 €. Am Wochenende waren drei Leute im Backend, und keiner will es gewesen sein. Mit dem Audit Log klärst du das mit ein paar Filterklicks statt in einer Teamrunde.

Das Problem

Shopware 6 bringt kein durchgängiges Änderungsprotokoll für die Administration mit, das Benutzer, Zeitpunkt und alten Wert an einer Stelle zeigt. Arbeiten mehrere Admins, eine Agentur und deine Warenwirtschaft am selben Shop, wird aus jeder Ungereimtheit Detektivarbeit. Das kostet Zeit. Und auf Dauer das Vertrauen im Team.

Die Lösung

Das Plugin schreibt jede Änderung, die ein angemeldeter Admin an den ausgewählten Datenarten vornimmt, in ein eigenes Protokoll: wer, wann, welcher Datensatz und ob er angelegt, geändert oder gelöscht wurde. Im Detailgrad „Feld-Diff (vorher/nachher)“ steht dazu jedes geänderte Feld mit altem und neuem Wert. Du findest alles unter Einstellungen > Erweiterungen > Audit Log, filterbar nach Benutzer, Entität, Operation und Zeitraum.

Was du davon hast

Streitfragen klärst du mit Fakten statt mit Vermutungen. Die Liste zeigt dir sofort, welcher Benutzer den Datensatz angefasst hat. Ein Klick auf den Eintrag zeigt Vorher und Nachher für jedes Feld.

An den Einträgen dreht niemand. Über die Administration und die Admin-API lässt sich kein Eintrag bearbeiten oder löschen, auch nicht mit vollen Administratorrechten. Ein Protokoll, das jeder umschreiben kann, ist wertlos. Dieses nicht.

Du bestimmst, wie viel gespeichert wird. Feld-Diff oder nur Metadaten, dazu genau die Entitäten, die dich interessieren. Ab Werk sind es Produkte, Bestellungen, Kunden, Benutzer und Rollen.

Datenschutz ist eingebaut, nicht nachgerüstet. Die IP-Erfassung ist aus, die Anonymisierung an. Passwörter, Tokens und Schlüssel erscheinen im Protokoll nur als „geschützt“. Nach Ablauf der Aufbewahrungsfrist räumt ein täglicher Task alte Einträge weg.

Das Protokoll bremst nicht und läuft nicht still voll. Das Plugin schreibt die Einträge im Hintergrund über die Message Queue, dein Team arbeitet in der Administration wie gewohnt weiter. Über der Liste siehst du jederzeit, wie groß das Protokoll ist. Führt dein Server keine geplanten Aufgaben aus, warnt dich das Audit Log, statt monatelang unbemerkt zu wachsen.

Auch Importe deiner Warenwirtschaft, wenn du willst. Schalte die Protokollierung von Integrationen ein, dann siehst du auch Änderungen, die über einen API-Zugang kommen. Große Synchronisationen verarbeitet das Plugin in Paketen zu 500 Einträgen.

So arbeitet das Plugin

• Erfasst werden Aktionen aus der Administration und, wenn eingeschaltet, von API-Integrationen. Änderungen durch Kunden im Shop, Konsolenbefehle und Hintergrundprozesse bleiben außen vor.
• Jeder Eintrag enthält Zeitpunkt, Benutzer, Entität, Datensatz-ID und Operation: Angelegt, Geändert oder Gelöscht.
• In der Detailansicht siehst du die Feldänderungen mit Vorher und Nachher. Beim Löschen hält der Eintrag den letzten Stand des Datensatzes fest.
• Die Aufbewahrungsfrist stellst du in Tagen ein. Standard sind 90 Tage, höchstens 180 Tage (sechs Monate).
• Mit „Maximale Anzahl Einträge“ setzt du eine Obergrenze. Darüber löscht die tägliche Bereinigung die ältesten Einträge, auch wenn ihre Frist noch läuft. Standard ist 0, also keine Obergrenze.
• Über der Liste zeigt die „Protokollgröße“ die Anzahl der Einträge, den ältesten Eintrag, Aufbewahrungsfrist, Obergrenze und die letzte Bereinigung. Hinkt die automatische Bereinigung hinterher, steht dort eine Warnung.
• Öffnest du eine Bestellung in der Administration und brichst die Bearbeitung ab, landet nichts im Protokoll. Gespeicherte Änderungen und Statuswechsel erscheinen als „Geändert“.
• Wer das Protokoll sehen darf, legst du in der Rollenverwaltung über das Recht „Audit Log“ fest. Ab Werk sehen es nur Administratoren.
• In der Plugin-Konfiguration weist ein Hinweis auf den Beschäftigtendatenschutz hin, damit du das Thema vor dem Einschalten klärst.

Typische Einsatzszenarien

Falscher Preis im Bestseller. Filter auf die Entität product und den Zeitraum setzen, Eintrag öffnen. Du siehst, wer den Preis wann von welchem Wert auf welchen gesetzt hat.

Die Agentur arbeitet mit. Deine Agentur pflegt Kategorien und Produkte. Du nimmst Kategorien in die erfassten Entitäten auf und siehst danach, welcher ihrer Benutzer was angelegt, geändert oder gelöscht hat.

Die Warenwirtschaft überschreibt Bestände. Dein ERP synchronisiert nachts über eine API-Integration. Mit eingeschalteter Integrations-Protokollierung erkennst du, ob ein Bestand vom Import kam oder von Hand geändert wurde.

Ein Kunde verlangt die Löschung seiner Daten. Deine IT entfernt mit einem Konsolenbefehl gezielt alle Protokolleinträge zu genau diesem Kunden, ohne den Rest des Protokolls anzufassen.

Technische Fakten für deine IT

• Shopware 6.7, PHP 8.2 oder neuer.
• Eine eigene Tabelle swp_audit_log. Shopware-Originaltabellen bleiben unverändert.
• Das Plugin sendet keine Daten an externe Server.
• Wird ein Benutzer oder eine Integration gelöscht, leert das Plugin nur den Verweis. Der gespeicherte Name bleibt im Eintrag.
• Schreiben asynchron über die Message Queue, in Nachrichten zu höchstens 500 Einträgen. Ohne laufenden Worker erscheinen Einträge entsprechend später.
• Ein täglicher Scheduled Task löscht Einträge nach Ablauf der Aufbewahrungsfrist und oberhalb der Obergrenze, ebenfalls in Paketen zu 500. Einen großen Rückstand arbeitet er in Folgenachrichten der Message Queue ab, höchstens 50.000 Einträge je Nachricht. So läuft kein einzelner Durchgang in ein Timeout.
• Entwurfsversionen, etwa eine in der Administration geöffnete Bestellung, werden nicht protokolliert, nur die gespeicherte Live-Version.
• Feldwerte über 5.000 Zeichen werden gekürzt. Felder mit Namen wie password, token, secret, hash oder apiKey werden nie im Klartext gespeichert.
• IP-Erfassung optional. Die Anonymisierung kürzt IPv4 um das letzte Oktett und IPv6 auf das 48-Bit-Netzpräfix.
• Admin-API: Lesen ja, Anlegen, Ändern und Löschen wird abgelehnt. Löschen nur über die Aufbewahrungsfrist und den Konsolenbefehl swp:audit-log:purge-entity, mit Trockenlauf-Option.
• Kein Storefront-Code: keine Auswirkung auf Theme, HTTP-Cache oder Ladezeit im Shop.
• Konfiguration gilt shopweit, nicht je Verkaufskanal.
• Deinstallation: Tabelle und Task werden entfernt, außer du behältst beim Deinstallieren die Plugin-Daten.

Ehrlich gesagt

Das Plugin zeigt dir den alten Wert, zurückschreiben musst du ihn selbst. Übersetzbare Texte wie Produktname oder Beschreibung erfasst diese Version nicht als Feldänderung, Anmeldungen protokolliert sie nicht, und einen CSV-Export gibt es nicht. Wer ein zertifiziertes Archiv nach GoBD braucht, ist hier falsch: Das Protokoll schützt vor Änderungen über Administration und API, nicht vor jemandem mit direktem Datenbankzugriff.

Häufige Fragen

Kann ich eine Änderung mit einem Klick rückgängig machen?

Nein. Das Plugin zeigt dir den alten Wert im Eintrag, zurücksetzen musst du ihn selbst im jeweiligen Bereich der Administration. Es ist ein Protokoll, keine Versionsverwaltung.

Werden auch Änderungen meiner Kunden im Shop protokolliert?

Nein. Erfasst werden nur Aktionen angemeldeter Admin-Benutzer und, wenn du es einschaltest, von API-Integrationen. Kundenkonten, Bestellungen aus dem Checkout, Konsolenbefehle und Hintergrundprozesse tauchen nicht auf.

Sehe ich auch Änderungen am Produktnamen oder an der Beschreibung?

Nicht als Feldänderung. Übersetzbare Texte speichert Shopware separat, diese Version erfasst sie nicht. Felder direkt am Produkt wie Preis, Bestand oder Aktiv-Status erscheinen dagegen mit Vorher und Nachher.

Ist das Protokoll wirklich revisionssicher?

Innerhalb von Shopware ja. Über die Administration und die Admin-API kann niemand einen Eintrag ändern oder löschen, auch kein Administrator. Wer direkten Zugriff auf die Datenbank hat, kann das weiterhin, ein zertifiziertes GoBD-Archiv ersetzt das Plugin nicht.

Wie steht es um DSGVO und Beschäftigtendatenschutz?

Das Plugin sendet keine Daten an externe Server, die IP-Erfassung ist ab Werk aus und die Aufbewahrungsfrist löscht alte Einträge automatisch. Einträge eines einzelnen Datensatzes entfernt ein Konsolenbefehl gezielt. Ob du Mitarbeiteraktivitäten protokollieren darfst, etwa mit Blick auf den Betriebsrat, klärst du bitte vorher selbst, die Konfiguration weist darauf hin.

Wird mein Shop oder die Administration dadurch langsamer?

Der Shop nicht, das Plugin hat keinen Storefront-Code. In der Administration landen die Einträge über die Message Queue im Hintergrund, das Speichern wartet also nicht auf das Protokoll. Damit die Tabelle nicht unbegrenzt wächst, begrenzt du sie über die Aufbewahrungsfrist und auf Wunsch über eine maximale Anzahl Einträge. Einen großen Rückstand löscht das Plugin in Etappen.

Wer darf das Protokoll sehen?

Administratoren und Benutzer mit dem Recht „Audit Log“ in der Stufe „Ansehen“. Ab Werk hat keine Rolle dieses Recht, du vergibst es bei Bedarf in der Rollenverwaltung. Ein Recht zum Bearbeiten oder Löschen gibt es bewusst nicht.

Was passiert, wenn ich einen Mitarbeiter-Account lösche?

Seine Einträge bleiben. Der Benutzername ist im Eintrag gespeichert, nur die Verknüpfung zum gelöschten Account wird geleert.

Funktioniert das mit meinem Theme und mehreren Verkaufskanälen?

Ja. Das Plugin arbeitet nur in der Administration und berührt kein Theme. Die Einstellungen gelten shopweit, weil Admin-Änderungen keinem Verkaufskanal gehören.

Was passiert bei der Deinstallation mit dem Protokoll?

Behältst du beim Deinstallieren die Plugin-Daten, bleibt die Tabelle mit allen Einträgen erhalten. Sonst entfernt das Plugin die Tabelle und den Bereinigungs-Task vollständig.