1
0
Files
breadcrumb-the-shire/tests/Service/User/UserLifecyclePolicyDashboardServiceTest.php

93 lines
3.6 KiB
PHP
Raw Normal View History

feat(user-lifecycle): cockpit foundation — KPI row + aside quick actions 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>
2026-04-26 20:36:28 +02:00
<?php
namespace MintyPHP\Tests\Service\User;
use MintyPHP\Repository\User\UserLifecyclePolicyDashboardRepositoryInterface;
use MintyPHP\Service\User\UserLifecyclePolicyDashboardService;
fix(user-lifecycle): track last-run state in core, not in audit log The "Last run" KPI tile stayed empty after a manual policy run, even though the run completed successfully. Two distinct bugs were involved: 1. The dashboard read latestSystemRun() from the audit log filtered by trigger_type='system'. UserLifecycleService::run() never sets that value — it uses 'manual' for actor-triggered runs and 'cron' for scheduled ones. The query never matched anything. 2. Even with the right trigger_type, the audit log only writes per-user entries (logDeactivate / logDelete / logDeleteFailure). A run that processes zero users — including most cron ticks on a healthy tenant — leaves no trace, so the tile would still show "—" after a correct execution. Both bugs share one root cause: run-trigger state was being inferred from audit-log details, but those are two semantically different things. Audit log answers "what did the run do?". A "last run" tile answers "did the run happen?". This commit moves run-trigger state to the core settings table and keeps the audit log strictly for per-user events: * Two new keys in core/Service/Settings/SettingKeys — USER_LIFECYCLE_LAST_RUN_AT_KEY and USER_LIFECYCLE_LAST_RUN_STATUS_KEY. * SettingsUserLifecycleGateway gains recordLastRun() and getLastRun(). UserSettingsGateway exposes them as recordLifecycleLastRun() / getLifecycleLastRun() so UserLifecycleService can call through its existing dependency without growing its constructor. * UserLifecycleService::run() writes both keys in finally — every time the lock was acquired, regardless of whether any user was processed and regardless of whether the run finished cleanly. Status reflects $result['ok'] ('success' / 'failed'). * UserLifecyclePolicyDashboardService gains a lastRun() reader. Action page now sources the KPI tile from this core service instead of the audit interface — so the tile works even when the audit module is disabled. * The audit-side lastRun() / latestSystemRun() / their tests are removed (YAGNI). Phase 4 (activity feed) can rebuild from the audit filter grid without a special method. Behaviorally: a no-op run now records "Last run: just now · ✓ Success" in the cockpit, exactly as expected. All six quality gates green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 21:07:57 +02:00
use MintyPHP\Service\User\UserSettingsGateway;
feat(user-lifecycle): cockpit foundation — KPI row + aside quick actions 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>
2026-04-26 20:36:28 +02:00
use PHPUnit\Framework\TestCase;
class UserLifecyclePolicyDashboardServiceTest extends TestCase
{
fix(user-lifecycle): track last-run state in core, not in audit log The "Last run" KPI tile stayed empty after a manual policy run, even though the run completed successfully. Two distinct bugs were involved: 1. The dashboard read latestSystemRun() from the audit log filtered by trigger_type='system'. UserLifecycleService::run() never sets that value — it uses 'manual' for actor-triggered runs and 'cron' for scheduled ones. The query never matched anything. 2. Even with the right trigger_type, the audit log only writes per-user entries (logDeactivate / logDelete / logDeleteFailure). A run that processes zero users — including most cron ticks on a healthy tenant — leaves no trace, so the tile would still show "—" after a correct execution. Both bugs share one root cause: run-trigger state was being inferred from audit-log details, but those are two semantically different things. Audit log answers "what did the run do?". A "last run" tile answers "did the run happen?". This commit moves run-trigger state to the core settings table and keeps the audit log strictly for per-user events: * Two new keys in core/Service/Settings/SettingKeys — USER_LIFECYCLE_LAST_RUN_AT_KEY and USER_LIFECYCLE_LAST_RUN_STATUS_KEY. * SettingsUserLifecycleGateway gains recordLastRun() and getLastRun(). UserSettingsGateway exposes them as recordLifecycleLastRun() / getLifecycleLastRun() so UserLifecycleService can call through its existing dependency without growing its constructor. * UserLifecycleService::run() writes both keys in finally — every time the lock was acquired, regardless of whether any user was processed and regardless of whether the run finished cleanly. Status reflects $result['ok'] ('success' / 'failed'). * UserLifecyclePolicyDashboardService gains a lastRun() reader. Action page now sources the KPI tile from this core service instead of the audit interface — so the tile works even when the audit module is disabled. * The audit-side lastRun() / latestSystemRun() / their tests are removed (YAGNI). Phase 4 (activity feed) can rebuild from the audit filter grid without a special method. Behaviorally: a no-op run now records "Last run: just now · ✓ Success" in the cockpit, exactly as expected. All six quality gates green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 21:07:57 +02:00
private function service(
?UserLifecyclePolicyDashboardRepositoryInterface $repository = null,
?UserSettingsGateway $settingsGateway = null
): UserLifecyclePolicyDashboardService {
return new UserLifecyclePolicyDashboardService(
$repository ?? $this->createMock(UserLifecyclePolicyDashboardRepositoryInterface::class),
$settingsGateway ?? $this->createMock(UserSettingsGateway::class)
);
}
feat(user-lifecycle): cockpit foundation — KPI row + aside quick actions 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>
2026-04-26 20:36:28 +02:00
public function testReturnsZeroWhenDeactivateDaysIsZero(): void
{
$repository = $this->createMock(UserLifecyclePolicyDashboardRepositoryInterface::class);
$repository->expects($this->never())->method('countPendingDeletion');
fix(user-lifecycle): track last-run state in core, not in audit log The "Last run" KPI tile stayed empty after a manual policy run, even though the run completed successfully. Two distinct bugs were involved: 1. The dashboard read latestSystemRun() from the audit log filtered by trigger_type='system'. UserLifecycleService::run() never sets that value — it uses 'manual' for actor-triggered runs and 'cron' for scheduled ones. The query never matched anything. 2. Even with the right trigger_type, the audit log only writes per-user entries (logDeactivate / logDelete / logDeleteFailure). A run that processes zero users — including most cron ticks on a healthy tenant — leaves no trace, so the tile would still show "—" after a correct execution. Both bugs share one root cause: run-trigger state was being inferred from audit-log details, but those are two semantically different things. Audit log answers "what did the run do?". A "last run" tile answers "did the run happen?". This commit moves run-trigger state to the core settings table and keeps the audit log strictly for per-user events: * Two new keys in core/Service/Settings/SettingKeys — USER_LIFECYCLE_LAST_RUN_AT_KEY and USER_LIFECYCLE_LAST_RUN_STATUS_KEY. * SettingsUserLifecycleGateway gains recordLastRun() and getLastRun(). UserSettingsGateway exposes them as recordLifecycleLastRun() / getLifecycleLastRun() so UserLifecycleService can call through its existing dependency without growing its constructor. * UserLifecycleService::run() writes both keys in finally — every time the lock was acquired, regardless of whether any user was processed and regardless of whether the run finished cleanly. Status reflects $result['ok'] ('success' / 'failed'). * UserLifecyclePolicyDashboardService gains a lastRun() reader. Action page now sources the KPI tile from this core service instead of the audit interface — so the tile works even when the audit module is disabled. * The audit-side lastRun() / latestSystemRun() / their tests are removed (YAGNI). Phase 4 (activity feed) can rebuild from the audit filter grid without a special method. Behaviorally: a no-op run now records "Last run: just now · ✓ Success" in the cockpit, exactly as expected. All six quality gates green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 21:07:57 +02:00
$this->assertSame(0, $this->service($repository)->pendingDeletionCount(0, 365, 7));
feat(user-lifecycle): cockpit foundation — KPI row + aside quick actions 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>
2026-04-26 20:36:28 +02:00
}
public function testReturnsZeroWhenDeleteDaysIsZero(): void
{
$repository = $this->createMock(UserLifecyclePolicyDashboardRepositoryInterface::class);
$repository->expects($this->never())->method('countPendingDeletion');
fix(user-lifecycle): track last-run state in core, not in audit log The "Last run" KPI tile stayed empty after a manual policy run, even though the run completed successfully. Two distinct bugs were involved: 1. The dashboard read latestSystemRun() from the audit log filtered by trigger_type='system'. UserLifecycleService::run() never sets that value — it uses 'manual' for actor-triggered runs and 'cron' for scheduled ones. The query never matched anything. 2. Even with the right trigger_type, the audit log only writes per-user entries (logDeactivate / logDelete / logDeleteFailure). A run that processes zero users — including most cron ticks on a healthy tenant — leaves no trace, so the tile would still show "—" after a correct execution. Both bugs share one root cause: run-trigger state was being inferred from audit-log details, but those are two semantically different things. Audit log answers "what did the run do?". A "last run" tile answers "did the run happen?". This commit moves run-trigger state to the core settings table and keeps the audit log strictly for per-user events: * Two new keys in core/Service/Settings/SettingKeys — USER_LIFECYCLE_LAST_RUN_AT_KEY and USER_LIFECYCLE_LAST_RUN_STATUS_KEY. * SettingsUserLifecycleGateway gains recordLastRun() and getLastRun(). UserSettingsGateway exposes them as recordLifecycleLastRun() / getLifecycleLastRun() so UserLifecycleService can call through its existing dependency without growing its constructor. * UserLifecycleService::run() writes both keys in finally — every time the lock was acquired, regardless of whether any user was processed and regardless of whether the run finished cleanly. Status reflects $result['ok'] ('success' / 'failed'). * UserLifecyclePolicyDashboardService gains a lastRun() reader. Action page now sources the KPI tile from this core service instead of the audit interface — so the tile works even when the audit module is disabled. * The audit-side lastRun() / latestSystemRun() / their tests are removed (YAGNI). Phase 4 (activity feed) can rebuild from the audit filter grid without a special method. Behaviorally: a no-op run now records "Last run: just now · ✓ Success" in the cockpit, exactly as expected. All six quality gates green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 21:07:57 +02:00
$this->assertSame(0, $this->service($repository)->pendingDeletionCount(180, 0, 7));
feat(user-lifecycle): cockpit foundation — KPI row + aside quick actions 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>
2026-04-26 20:36:28 +02:00
}
public function testReturnsZeroWhenWindowDaysIsZeroOrNegative(): void
{
$repository = $this->createMock(UserLifecyclePolicyDashboardRepositoryInterface::class);
$repository->expects($this->never())->method('countPendingDeletion');
fix(user-lifecycle): track last-run state in core, not in audit log The "Last run" KPI tile stayed empty after a manual policy run, even though the run completed successfully. Two distinct bugs were involved: 1. The dashboard read latestSystemRun() from the audit log filtered by trigger_type='system'. UserLifecycleService::run() never sets that value — it uses 'manual' for actor-triggered runs and 'cron' for scheduled ones. The query never matched anything. 2. Even with the right trigger_type, the audit log only writes per-user entries (logDeactivate / logDelete / logDeleteFailure). A run that processes zero users — including most cron ticks on a healthy tenant — leaves no trace, so the tile would still show "—" after a correct execution. Both bugs share one root cause: run-trigger state was being inferred from audit-log details, but those are two semantically different things. Audit log answers "what did the run do?". A "last run" tile answers "did the run happen?". This commit moves run-trigger state to the core settings table and keeps the audit log strictly for per-user events: * Two new keys in core/Service/Settings/SettingKeys — USER_LIFECYCLE_LAST_RUN_AT_KEY and USER_LIFECYCLE_LAST_RUN_STATUS_KEY. * SettingsUserLifecycleGateway gains recordLastRun() and getLastRun(). UserSettingsGateway exposes them as recordLifecycleLastRun() / getLifecycleLastRun() so UserLifecycleService can call through its existing dependency without growing its constructor. * UserLifecycleService::run() writes both keys in finally — every time the lock was acquired, regardless of whether any user was processed and regardless of whether the run finished cleanly. Status reflects $result['ok'] ('success' / 'failed'). * UserLifecyclePolicyDashboardService gains a lastRun() reader. Action page now sources the KPI tile from this core service instead of the audit interface — so the tile works even when the audit module is disabled. * The audit-side lastRun() / latestSystemRun() / their tests are removed (YAGNI). Phase 4 (activity feed) can rebuild from the audit filter grid without a special method. Behaviorally: a no-op run now records "Last run: just now · ✓ Success" in the cockpit, exactly as expected. All six quality gates green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 21:07:57 +02:00
$service = $this->service($repository);
feat(user-lifecycle): cockpit foundation — KPI row + aside quick actions 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>
2026-04-26 20:36:28 +02:00
$this->assertSame(0, $service->pendingDeletionCount(180, 365, 0));
$this->assertSame(0, $service->pendingDeletionCount(180, 365, -1));
}
public function testDelegatesToRepositoryWhenAllPolicyValuesPositive(): void
{
$repository = $this->createMock(UserLifecyclePolicyDashboardRepositoryInterface::class);
$repository->expects($this->once())
->method('countPendingDeletion')
->with(365, 7)
->willReturn(42);
fix(user-lifecycle): track last-run state in core, not in audit log The "Last run" KPI tile stayed empty after a manual policy run, even though the run completed successfully. Two distinct bugs were involved: 1. The dashboard read latestSystemRun() from the audit log filtered by trigger_type='system'. UserLifecycleService::run() never sets that value — it uses 'manual' for actor-triggered runs and 'cron' for scheduled ones. The query never matched anything. 2. Even with the right trigger_type, the audit log only writes per-user entries (logDeactivate / logDelete / logDeleteFailure). A run that processes zero users — including most cron ticks on a healthy tenant — leaves no trace, so the tile would still show "—" after a correct execution. Both bugs share one root cause: run-trigger state was being inferred from audit-log details, but those are two semantically different things. Audit log answers "what did the run do?". A "last run" tile answers "did the run happen?". This commit moves run-trigger state to the core settings table and keeps the audit log strictly for per-user events: * Two new keys in core/Service/Settings/SettingKeys — USER_LIFECYCLE_LAST_RUN_AT_KEY and USER_LIFECYCLE_LAST_RUN_STATUS_KEY. * SettingsUserLifecycleGateway gains recordLastRun() and getLastRun(). UserSettingsGateway exposes them as recordLifecycleLastRun() / getLifecycleLastRun() so UserLifecycleService can call through its existing dependency without growing its constructor. * UserLifecycleService::run() writes both keys in finally — every time the lock was acquired, regardless of whether any user was processed and regardless of whether the run finished cleanly. Status reflects $result['ok'] ('success' / 'failed'). * UserLifecyclePolicyDashboardService gains a lastRun() reader. Action page now sources the KPI tile from this core service instead of the audit interface — so the tile works even when the audit module is disabled. * The audit-side lastRun() / latestSystemRun() / their tests are removed (YAGNI). Phase 4 (activity feed) can rebuild from the audit filter grid without a special method. Behaviorally: a no-op run now records "Last run: just now · ✓ Success" in the cockpit, exactly as expected. All six quality gates green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 21:07:57 +02:00
$this->assertSame(42, $this->service($repository)->pendingDeletionCount(180, 365, 7));
feat(user-lifecycle): cockpit foundation — KPI row + aside quick actions 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>
2026-04-26 20:36:28 +02:00
}
public function testReturnsRepositoryCountVerbatim(): void
{
$repository = $this->createMock(UserLifecyclePolicyDashboardRepositoryInterface::class);
$repository->method('countPendingDeletion')->willReturn(0);
fix(user-lifecycle): track last-run state in core, not in audit log The "Last run" KPI tile stayed empty after a manual policy run, even though the run completed successfully. Two distinct bugs were involved: 1. The dashboard read latestSystemRun() from the audit log filtered by trigger_type='system'. UserLifecycleService::run() never sets that value — it uses 'manual' for actor-triggered runs and 'cron' for scheduled ones. The query never matched anything. 2. Even with the right trigger_type, the audit log only writes per-user entries (logDeactivate / logDelete / logDeleteFailure). A run that processes zero users — including most cron ticks on a healthy tenant — leaves no trace, so the tile would still show "—" after a correct execution. Both bugs share one root cause: run-trigger state was being inferred from audit-log details, but those are two semantically different things. Audit log answers "what did the run do?". A "last run" tile answers "did the run happen?". This commit moves run-trigger state to the core settings table and keeps the audit log strictly for per-user events: * Two new keys in core/Service/Settings/SettingKeys — USER_LIFECYCLE_LAST_RUN_AT_KEY and USER_LIFECYCLE_LAST_RUN_STATUS_KEY. * SettingsUserLifecycleGateway gains recordLastRun() and getLastRun(). UserSettingsGateway exposes them as recordLifecycleLastRun() / getLifecycleLastRun() so UserLifecycleService can call through its existing dependency without growing its constructor. * UserLifecycleService::run() writes both keys in finally — every time the lock was acquired, regardless of whether any user was processed and regardless of whether the run finished cleanly. Status reflects $result['ok'] ('success' / 'failed'). * UserLifecyclePolicyDashboardService gains a lastRun() reader. Action page now sources the KPI tile from this core service instead of the audit interface — so the tile works even when the audit module is disabled. * The audit-side lastRun() / latestSystemRun() / their tests are removed (YAGNI). Phase 4 (activity feed) can rebuild from the audit filter grid without a special method. Behaviorally: a no-op run now records "Last run: just now · ✓ Success" in the cockpit, exactly as expected. All six quality gates green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 21:07:57 +02:00
$this->assertSame(0, $this->service($repository)->pendingDeletionCount(180, 365, 7));
}
public function testLastRunReturnsNullWhenSettingsHaveNoRecord(): void
{
$settingsGateway = $this->createMock(UserSettingsGateway::class);
$settingsGateway->expects($this->once())
->method('getLifecycleLastRun')
->willReturn(null);
$this->assertNull($this->service(null, $settingsGateway)->lastRun());
}
public function testLastRunReturnsRecordedSettingsVerbatim(): void
{
$settingsGateway = $this->createMock(UserSettingsGateway::class);
$settingsGateway->method('getLifecycleLastRun')->willReturn([
'created_at' => '2026-04-26 17:30:00',
'status' => 'success',
]);
$row = $this->service(null, $settingsGateway)->lastRun();
feat(user-lifecycle): cockpit foundation — KPI row + aside quick actions 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>
2026-04-26 20:36:28 +02:00
fix(user-lifecycle): track last-run state in core, not in audit log The "Last run" KPI tile stayed empty after a manual policy run, even though the run completed successfully. Two distinct bugs were involved: 1. The dashboard read latestSystemRun() from the audit log filtered by trigger_type='system'. UserLifecycleService::run() never sets that value — it uses 'manual' for actor-triggered runs and 'cron' for scheduled ones. The query never matched anything. 2. Even with the right trigger_type, the audit log only writes per-user entries (logDeactivate / logDelete / logDeleteFailure). A run that processes zero users — including most cron ticks on a healthy tenant — leaves no trace, so the tile would still show "—" after a correct execution. Both bugs share one root cause: run-trigger state was being inferred from audit-log details, but those are two semantically different things. Audit log answers "what did the run do?". A "last run" tile answers "did the run happen?". This commit moves run-trigger state to the core settings table and keeps the audit log strictly for per-user events: * Two new keys in core/Service/Settings/SettingKeys — USER_LIFECYCLE_LAST_RUN_AT_KEY and USER_LIFECYCLE_LAST_RUN_STATUS_KEY. * SettingsUserLifecycleGateway gains recordLastRun() and getLastRun(). UserSettingsGateway exposes them as recordLifecycleLastRun() / getLifecycleLastRun() so UserLifecycleService can call through its existing dependency without growing its constructor. * UserLifecycleService::run() writes both keys in finally — every time the lock was acquired, regardless of whether any user was processed and regardless of whether the run finished cleanly. Status reflects $result['ok'] ('success' / 'failed'). * UserLifecyclePolicyDashboardService gains a lastRun() reader. Action page now sources the KPI tile from this core service instead of the audit interface — so the tile works even when the audit module is disabled. * The audit-side lastRun() / latestSystemRun() / their tests are removed (YAGNI). Phase 4 (activity feed) can rebuild from the audit filter grid without a special method. Behaviorally: a no-op run now records "Last run: just now · ✓ Success" in the cockpit, exactly as expected. All six quality gates green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 21:07:57 +02:00
$this->assertIsArray($row);
$this->assertSame('2026-04-26 17:30:00', $row['created_at']);
$this->assertSame('success', $row['status']);
feat(user-lifecycle): cockpit foundation — KPI row + aside quick actions 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>
2026-04-26 20:36:28 +02:00
}
}