Zum Inhalt

FAQ – Admin-Aktivitätsprotokoll

Allgemeine Fragen

Verlangsamt das Plugin den Admin?

Marginal. Jede Schreib-Operation im Admin-Context bekommt einen zusätzlichen DB-INSERT in die kommora_activity_log-Tabelle. Auf produktiven Shops mit < 1000 Schreib-Operationen pro Tag ist das nicht messbar. Bei sehr hoher Schreib-Last (z. B. Massen-Import via Plugin) können mehrere Tausend Einträge entstehen — die Tabelle sollte regelmäßig durch den Purge-Task bereinigt werden (passiert automatisch, wenn der Messenger-Worker läuft).

Was passiert bei einem Logging-Fehler?

Logging-Fehler werden stillschweigend abgefangen und blockieren niemals die eigentliche Admin-Operation. Wenn z. B. die kommora_activity_log-Tabelle gerade nicht erreichbar ist, wird die Produktbearbeitung im Admin trotzdem normal durchgehen — nur der Log-Eintrag fehlt dann. Dieser Robustheits-Trade-Off ist bewusst gewählt: ein Logging-Plugin darf das Backoffice nicht handlungsunfähig machen.

Kann ich rückwirkend Daten erfassen, die vor der Plugin-Installation gemacht wurden?

Nein. Die Erfassung startet ab dem Moment der Aktivierung. Was davor passiert ist, wurde nicht protokolliert und ist nicht rekonstruierbar.

DSGVO & Datenschutz

Ist das Plugin DSGVO-konform?

Per Default ja — IP und User-Agent werden nicht erfasst, sensitive Felder maskiert, automatische Löschung nach 365 Tagen. Aber: du selbst musst deinen DSGVO-Pflichten nachkommen (Verarbeitungsverzeichnis, Information der Admin-User, ggf. Betriebsrat). Details in den DSGVO-Hinweisen.

Werden Passwörter im Klartext gespeichert?

Nein, niemals. Felder mit Sensitive-Keys (password, secret, apiKey, token, salt, hash und weitere) werden im Diff automatisch als *** ersetzt. Diese Maskierung ist nicht abschaltbar und wirkt sich auch auf Custom-Plugin-Felder aus, deren Name diese Sensitiven-Patterns enthält.

Sehen meine Mitarbeiter, dass sie protokolliert werden?

Das Plugin selbst zeigt im Backoffice keinen Hinweis an. Du musst die Information aktiv geben — i. d. R. via Onboarding-Dokument, Mitarbeiter-Information oder Aushang. Das ist eine DSGVO-Anforderung nach Art. 13.

Was bei einem Sicherheitsvorfall, der das Plugin selbst betrifft?

Wenn die kommora_activity_log-Tabelle kompromittiert wäre (z. B. SQL-Injection in einem anderen Plugin), könnten Angreifer historische Audit-Daten löschen oder einsehen. Härtungs-Maßnahmen: separate DB-User für Backup-Reads, Read-Replica für Audit-Auswertungen, regelmäßige Off-Site-Backups der Tabelle.

Technische Details

In welcher Tabelle liegen die Daten?

kommora_activity_log in der Shopware-DB. Schema-Details siehe Konfiguration. Bei Deinstallation mit keepUserData=false wird die Tabelle gelöscht.

Wie löse ich den Purge-Task manuell aus? 
bin/console scheduled-task:run --task=kommora_activity_log.purge

Der Task verarbeitet maximal 500 Einträge pro Lauf. Bei größeren Backlogs den Befehl mehrfach laufen lassen — oder einfach den Scheduler regulär laufen lassen.

Kann ich Einträge manuell löschen?

Über die Admin-UI nicht — bewusst, weil Audit-Logs nicht selektiv manipulierbar sein sollen (sonst wären sie keine Audits). Wenn du wirklich einzelne Einträge löschen musst (z. B. nach DSGVO-Anonymisierung eines ausgeschiedenen Mitarbeiters), direkt per SQL:

DELETE FROM kommora_activity_log WHERE id = UNHEX(REPLACE('uuid', '-', ''));
Wie viel Speicherplatz braucht das Log typisch?

Pro Eintrag ca. 1–3 KB (variiert mit Diff-Größe). Bei einem mittelgroßen Shop mit 5 Admin-Usern und 200 Schreib-Operationen pro Tag → ~500 KB pro Tag, ~180 MB pro Jahr. Bei großen Importen können einzelne Operationen mehrere Tausend Einträge erzeugen.

Funktioniert das Plugin in Shopware Cloud?

Ja. Keine eigenen Composer-Abhängigkeiten, keine File-System-Schreibzugriffe (außer der DB-Tabelle), kein Eingriff in den Bootloader. Standard-Shopware-Subscriber-Pattern.

Kategorien & Filterung

Wieso fehlen meine Storefront-Aktivitäten?

Bewusst — das Plugin protokolliert ausschließlich Admin-Context-Aktionen (actor_type = admin oder integration). Schreib-Operationen aus dem Storefront (Customer-Adress-Änderung, Newsletter-Eintrag, Bestellung anlegen) gehören nicht hierhin — das wäre Customer-Auditing, deutlich umfangreicher und mit anderem Datenschutz-Profil.

Wie erkenne ich automatisierte Aktionen (Cron-Jobs, Plugin-Subscriber)?

Über actor_type = system. Diese Einträge haben keinen User-Bezug — sie kommen aus Shopware-internen Schritten oder Plugin-Schedulers.

Mein eigenes Plugin macht viele Updates — kann ich es vom Logging ausschließen?

Ja. Du kannst in der EntityWrittenSubscriber.php-Konfig zusätzliche entity_name-Werte zur Excluded-Liste hinzufügen. Aber: das ist ein Custom-Patch des Plugins, nicht via UI konfigurierbar. Bei Bedarf bei support@kommora.de melden — wir prüfen, ob die Excluded-Liste konfigurierbar gemacht werden sollte.

Performance & Skalierung

Was bei 10+ Admin-Usern und 5000 Schreib-Operationen pro Tag?

Funktioniert weiterhin, aber:

  • Aufbewahrungsdauer ggf. kürzen (90 oder 180 Tage statt 365)
  • Sicherstellen, dass der Scheduled-Task-Worker stabil läuft (Purge muss durchkommen, sonst wächst die Tabelle)
  • Auf der kommora_activity_log-Tabelle existieren Indizes auf category, actor_user_id, created_at — bei sehr großen Volumen kann ein zusätzlicher Composite-Index auf (category, created_at) helfen (per Migration einbauen)
Funktioniert das mit Shopware-Cluster (Multi-Server)?

Ja. Schreib-Operationen werden auf jedem Node erfasst, die DB-Tabelle ist zentral. Purge-Task läuft auf einem Node (typisch dem Worker-Node).

Kommt nicht weiter?

E-Mail an support@kommora.de mit:

  • Shopware-Version
  • Plugin-Version
  • Beschreibung des Problems
  • Auszug aus var/log/prod-*.log rund um den Fehlerzeitpunkt
  • ggf. Inhalt der Plugin-Konfig (anonymisiert)

Antwortzeit: 1 Werktag.