Files

fs 141f0a0155 refactor: extract shared code from bin/ scripts and remove legacy scheduler runner

- Extract ModuleManifestLoader for standalone manifest loading (used by
  module-deactivate and ValidateCommand)
- Extract SqlStatementParser, ModuleMigrationRepository, and
  ModuleMigrationService from bin/module-migrate.php to enforce strict
  layering (SQL in repository, orchestration in service)
- Delete bin/scheduler-run.php (fully superseded by bin/console scheduler:run)
- Update docs and test fixtures to reference bin/console

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

2026-03-22 13:45:16 +01:00

3.0 KiB

Raw Blame History

Benutzer-Lifecycle-Policy

Letzte Aktualisierung: 2026-03-06

Ziel

Globale Regeln für automatische Benutzer-Deaktivierung und spätere Löschung.

Stufe 1: Benutzer wird auf inactive gesetzt.
Stufe 2: Inaktiver Benutzer wird nach weiterer Frist gelöscht (Hard Delete).

Settings

Die Regeln werden in settings gespeichert:

user_inactivity_deactivate_days
user_inactivity_delete_days

Semantik:

Wertebereich: 0..3650
0 deaktiviert die jeweilige Regel
Löschung wird nur angewendet, wenn Deaktivierung aktiv ist (deactivate > 0)

Defaults:

Deaktivierung: 180
Löschung: 365 (ab Inaktivsetzung)

Referenzdaten

Deaktivierung basiert auf COALESCE(last_login_at, created).
Löschung basiert auf active_changed_at (nur wenn gesetzt).

Privilegierte Benutzer (ausgenommen)

Automatische Lifecycle-Aktionen ignorieren Benutzer mit mindestens einer aktiven Rolle, die eine der Permissions hat:

settings.update
tenants.update

Ausführung

Manueller Run (Admin UI)

Endpoint: POST /admin/settings/run-user-lifecycle
Schutz: Login + settings.update + CSRF
Verdrahtung: SchedulerServicesFactory erstellt UserLifecycleService instanzbasiert.

Cron/CLI

Bevorzugt über den zentralen Scheduler:
- Kommando: bin/console scheduler:run (führt fällige Jobs aus, inkl. user_lifecycle_run)
- Beispiel (minütlich):

* * * * * docker compose exec php php bin/console scheduler:run

Exit-Codes:

0 erfolgreich
1 Fehler/Lock-Konflikt

Concurrency

Zur Vermeidung paralleler Runs wird ein MySQL-Lock verwendet:

GET_LOCK('user_lifecycle_maintenance', 0)
RELEASE_LOCK('user_lifecycle_maintenance')

Session-Wirkung

Wenn ein bereits eingeloggter Benutzer automatisch deaktiviert wurde, greift die bestehende Session-Refresh-Logik beim nächsten Request und führt zum Logout.

Audit-Log (Delete/Restore)

Lifecycle-Events werden in user_lifecycle_audit_log protokolliert.

deactivate: erfolgreich ausgeführte automatische Deaktivierung
delete: Löschversuch mit Snapshot
restore: Wiederherstellung aus einem Delete-Event

Wichtige Regeln:

Delete ist fail-closed: ohne erfolgreich gespeicherten Snapshot wird nicht gelöscht.
Snapshot wird verschlüsselt in snapshot_enc gespeichert.
Snapshot enthält nur whitelisted Profilfelder (keine Secrets/Tokens).
Audit-Retention: 365 Tage (POST /admin/user-lifecycle-audit/purge).

Wiederherstellung (ohne Assignments)

Restore ist nur für action=delete + status=success möglich und nur einmal pro Event.

Konfliktregeln (Hard fail):

UUID existiert bereits
E-Mail existiert bereits

Restore-Ergebnis:

User wird neu angelegt mit Snapshot-Stammdaten
active=0
zufälliges Passwort
keine Wiederherstellung von Tenant-/Role-/Department-Zuweisungen

Rechte

Ansicht Lifecycle-Protokolle: user_lifecycle_audit.view
Wiederherstellen aus Lifecycle-Protokoll: users.lifecycle_restore
Purge: settings.update

3.0 KiB Raw Blame History