fs
cc2cf3a254
Phase 1 of the Stripe-style policy-cockpit redesign for the user-lifecycle
settings page. Pure server-rendering — no async, no JS components, no
sparklines yet (those land in later phases).
Adds a four-tile KPI row above the configuration form (Last run,
Deactivated/30d, Deleted/30d, Pending deletion/7d), populates the
previously empty aside with three quick actions (Run policy now,
Purge logs, Policy reference link), and surfaces a relative-time +
status hint under the existing Run-Now collapsible.
Module-isolation is preserved through a new read-side contract:
* core/Service/Audit/UserLifecycleAuditDashboardInterface — read-only
pendant to the existing write-side UserLifecycleAuditInterface.
Methods: lastRun(), summaryByAction(int days), countActionInWindow(...).
* core/Service/Audit/NullUserLifecycleAuditDashboard — fail-closed
default when the audit module is disabled. KPI tiles 1-3 then
render "—"; tile 4 (pending deletion) keeps working because it
lives in the core domain.
* modules/audit/.../Service/UserLifecycleAuditDashboardService — the
module's implementation; reads through the existing
UserLifecycleAuditRepository (extended with three new aggregation
queries: lastRun, countByActionStatusSinceTimestamp, countSinceTimestamp).
* AuditContainerRegistrar binds the interface to the module impl;
registerContainer.php registers the Null fallback before module
bindings, mirroring how the write-side audit interface is wired.
The new core service UserLifecyclePolicyDashboardService computes
the pending-deletion-window count from the users table directly
(no audit dependency) — defensive when both policy days are 0
(returns 0 rather than running an unbounded query).
New shared template partial templates/partials/app-kpi-row.phtml is
generic — accepts a $kpiTiles array of {label, count, icon, iconTone,
href, tooltip} and reuses the existing app-tile primitive. Other
settings pages can pick it up without ceremony.
Includes:
* PHPUnit tests for both new services (happy path + Null-fallback +
policy-disabled edge cases).
* AuditModuleIsolationContractTest allowlist extended for the new
interface and module service.
* 14 new translation keys in both default_de.json and default_en.json
(i18n parity verified).
All six quality gates green.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tests
Ziel
Die Tests sind nach Schutzwirkung organisiert, nicht nur nach technischer Ebene. Wichtige Architektur- und Security-Invarianten sollen schnell gezielt laufen koennen, ohne dass jede Aenderung immer die komplette Suite im Kopf behalten muss.
PHPUnit-Suiten
CoreCore: gesamte Test-Suite.Unit: kleine verhaltensorientierte Unit-Tests ohne breites Orchestrierungs-Setup.Service: Business-Logik, Policies, Gateways und Orchestrierungs-Tests untertests/Service/.Repository: Query- und Repository-Tests untertests/Repository/.Domain: fachliche Taxonomie- und Domain-Tests untertests/Domain/.Architecture: alle Architektur-Contracts untertests/Architecture/.ArchitectureCore: Core-Boundaries, Module-/Repository-Contracts, Taxonomie- und Sync-Contracts.ArchitectureSecurity: CSRF, PRG, File-Storage, Crypto, Logging sowie AuthZ-nahe Contracts.ArchitectureUI: UI-Contracts fuer Listen, Detailseiten, Runtime-Komponenten und A11y.ArchitectureModules: modulbezogene Struktur- und Isolations-Contracts.ArchitectureMeta: Agent-/Skill-/Meta-Contracts fuer das Repository-Setup.
Regeln fuer neue Architecture-Tests
- Nur stabile Invarianten testen, keine einmaligen Migrationsdetails.
- Guards oder Risiken explizit abdecken, zum Beispiel
GR-CORE-*,GR-SEC-*,GR-TEST-*. - Keine Duplikate neben bereits breiten Contracts anlegen.
- String-Assertions nur verwenden, wenn kein robusterer Contract moeglich ist.
- Monolithische Sammeltests vermeiden; lieber kleine thematische Contracts.
Delete vs. Refactor vs. Keep
keep: testet einen echten plattformweiten Contract oder Security-Guard.refactor: Schutz ist wichtig, aber der Test ist zu datei-, markup- oder implementation-detailnah.delete: dupliziert bestehende Schutzwirkung oder prueft nur historische Altlasten.
Regeln fuer neue Service-Tests
- Services auf Guards, Orchestrierung, Normalisierung, Fehlerpfade und Seiteneffekte testen.
- Keine eigenen Tests fuer reine
find/list/get/set-Delegation ohne zusaetzliche Regel. - Thin Wrapper auf gemeinsame Primitive zentral testen, nicht pro Gateway erneut.
- Mockability-, Reflection- und Interface-Existenz-Tests ohne Risiko-Schutz vermeiden.
- Kleine Normalisierungs-Matrizen mit DataProvidern oder zusammengezogenen Contract-Dateien verdichten.
Typische Low-Value-Muster
- Gateway-Test prueft nur
encrypt/decrypterneut, obwohl das Basisverhalten schon zentral abgesichert ist. - Test bestaetigt nur, dass ein Service eins zu eins an Repository oder Gateway weiterreicht.
- Test prueft nur Methodensignatur, Reflection oder dass eine Klasse mockbar ist.
- Mehrere Minidateien decken denselben Settings-/Fallback-Mechanismus mit identischem Mock-Muster ab.
Naechste Audit-Kandidaten
- methodenweiser Low-value-Pass in
tests/Service/User/UserAccountServiceTest.php - methodenweiser Low-value-Pass in
tests/Service/Org/DepartmentServiceTest.php - methodenweiser Low-value-Pass in
tests/Service/Access/RoleServiceTest.php - verbleibende kleine Settings-Gateway-Tests auf weitere Verdichtung pruefen