Zum Inhalt

Konfiguration – Admin-Aktivitätsprotokoll

Alle Einstellungen liegen unter Admin → Einstellungen → System → Plugins → KommoraAdminActivityLog.

Bereich „Aufbewahrung & Datenschutz"

Option Default Beschreibung
Aufbewahrungsdauer (Tage) 365 Einträge älter als X Tage werden vom täglichen Scheduled-Task kommora_activity_log.purge automatisch gelöscht. Setze auf einen für deine Branche/Audit-Anforderung passenden Wert: 30 Tage (minimal), 365 (Standard), 730 (für Branchen mit längeren Audit-Zyklen). Auf 0 oder negative Werte gesetzt: keine automatische Löschung — manuell verantworten.
IP-Adresse des Bearbeiters speichern aus Wenn ein, wird die Client-IP-Adresse beim Logging gespeichert. DSGVO-Hinweis: IP-Adressen sind personenbezogene Daten. Aktivieren nur, wenn ein berechtigtes Interesse vorliegt (z. B. konkrete Audit-Anforderung), und die Verarbeitung im Verzeichnis dokumentieren.
User-Agent / Browser-Kennung speichern aus Wenn ein, wird der User-Agent-Header beim Logging gespeichert. DSGVO-Hinweis: User-Agents können als digitaler Fingerprint dienen — gleicher Datenschutz-Maßstab wie bei IP. Aktivieren nur mit berechtigtem Interesse.
Datenminimierung als Default-Prinzip

Beide Erfassungs-Optionen (IP + User-Agent) sind in der Standard-Konfig deaktiviert. Das Plugin ist absichtlich „opt-in" für diese sensiblen Felder — DSGVO-Datenminimierung (Art. 5 Abs. 1 lit. c DSGVO) verlangt, dass nur das Nötigste erhoben wird. Wenn dein Audit-Konzept beide Felder explizit verlangt, aktiviere sie und dokumentiere den Zweck im Verarbeitungsverzeichnis.

Was wird trotzdem immer geloggt?

Unabhängig von den oben genannten Optionen wird immer Folgendes protokolliert:

  • actor_user_id — UUID des Admin-Users, der die Aktion durchgeführt hat
  • actor_username — Benutzername (zur Lesbarkeit der Liste)
  • actor_type — admin (interaktiver Login), integration (Integrations-Token), system (interne Operation)
  • category — automatisch berechnete Rubrik aus 13 Kategorien (siehe Kategorien)
  • action — create / update / delete / login_success / login_failed / plugin_install etc.
  • entity_name — z. B. product, customer, order, system_config
  • entity_id — UUID der betroffenen Entität
  • entity_label — menschenlesbarer Name (Produktname, Kundenname, Order-Nummer)
  • diff — JSON mit Vorher/Nachher pro Feld (sensitive Felder als *** maskiert)
  • created_at — Zeitstempel

Diese Felder sind die Mindestbasis für ein nachvollziehbares Audit-Log und können nicht deaktiviert werden.

Sensitive-Felder-Maskierung (automatisch)

Folgende Feld-Keys werden im diff automatisch als *** gespeichert — sie tauchen niemals im Klartext im Log auf:

  • password
  • secret
  • apiKey / api_key
  • token / accessToken / refreshToken
  • salt
  • hash

Plus weitere typische Sensitive-Patterns (Heuristik im DiffCalculator). Die Maskierung ist nicht abschaltbar — wenn ein Custom-Plugin ein Feld myCustomPassword hat, wird es ebenfalls als *** gespeichert.

Was wird nicht geloggt (Excluded Entities)

Folgende Entities werden bewusst nicht protokolliert (verhindert Log-Spam / Rekursion):

  • kommora_activity_log (das Log selbst)
  • user_recovery, refresh_token (Auth-Internals)
  • cart (zu häufig, nicht-persistent)
  • notification (Admin-UI-Pop-ups)
  • alle Tabellen mit Suffix _translation oder _tag (Übersetzungen + Tag-Verknüpfungen werden via Parent-Entity erfasst)
  • weitere Internals (Vollständige Liste im Plugin-Code unter Subscriber/EntityWrittenSubscriber.php)

No-Op-Update-Filter

Wenn ein Update-Vorgang keine echten Feld-Änderungen enthält (z. B. ein DAL-Update, das nur den updated_at-Timestamp ändert), wird kein Log-Eintrag erstellt. Verhindert Spam durch sinnlose Einträge bei Plugins, die ohne tatsächliche Änderungen update() aufrufen.

Scheduled-Task „Purge"

Der Scheduled Task kommora_activity_log.purge läuft täglich und löscht Einträge älter als die konfigurierte Aufbewahrungsdauer in 500er-Blöcken.

  • Default-Intervall: 86400 Sekunden (24 h)
  • Batch-Größe: 500 Einträge pro Iteration
  • Memory-effizient: kein DELETE … WHERE auf großen Tabellen, sondern paginiertes Lade-und-Lösch-Pattern (verhindert MySQL-Lock-Timeouts bei sehr großen Logs)

Manuell auslösen:

bin/console scheduled-task:run --task=kommora_activity_log.purge

ACL-Berechtigung

Das Plugin definiert die neue Permission kommora_activity_log:read. Nur Rollen mit dieser Permission sehen das Modul im linken Admin-Menü unter Erweiterungen → Other.

Beim ersten Aktivieren musst du die Permission mind. einer Rolle (idealerweise nur „Administrator") zuweisen:

  1. Admin → Einstellungen → System → Benutzer & Rechte → Rollen
  2. Rolle öffnen
  3. Unter „Andere" → „Aktivitätsprotokoll lesen" → aktivieren
  4. Speichern

Speichern

Plugin-Konfig speichern → die Werte werden bei jedem Logging-Aufruf neu aus der System-Config gelesen, kein zusätzliches Cache-Leeren nötig. Änderungen an der Aufbewahrungsdauer greifen ab dem nächsten Lauf des Purge-Tasks.

Weiter