forked from fa/breadcrumb-the-shire
fs
06118c1b26
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>
42 lines
1.3 KiB
PHP
42 lines
1.3 KiB
PHP
<?php
|
|
|
|
namespace MintyPHP\Service\User;
|
|
|
|
use MintyPHP\Repository\User\UserLifecyclePolicyDashboardRepositoryInterface;
|
|
|
|
/**
|
|
* Computes the core-domain KPIs for the user lifecycle settings dashboard.
|
|
*
|
|
* "Pending deletion" reads the users table directly. "Last run" reads the
|
|
* settings table where UserLifecycleService::run() records every invocation
|
|
* (success, failed, no-op alike) — independent of the audit module, so the
|
|
* tile works even when audit is disabled.
|
|
*
|
|
* @api
|
|
*/
|
|
final class UserLifecyclePolicyDashboardService
|
|
{
|
|
public function __construct(
|
|
private readonly UserLifecyclePolicyDashboardRepositoryInterface $userLifecyclePolicyDashboardRepository,
|
|
private readonly UserSettingsGateway $userSettingsGateway
|
|
) {
|
|
}
|
|
|
|
public function pendingDeletionCount(int $deactivateDays, int $deleteDays, int $windowDays = 7): int
|
|
{
|
|
if ($deactivateDays <= 0 || $deleteDays <= 0 || $windowDays <= 0) {
|
|
return 0;
|
|
}
|
|
return $this->userLifecyclePolicyDashboardRepository->countPendingDeletion($deleteDays, $windowDays);
|
|
}
|
|
|
|
/**
|
|
* @return array{created_at: string, status: string}|null
|
|
* null when no run has been recorded yet.
|
|
*/
|
|
public function lastRun(): ?array
|
|
{
|
|
return $this->userSettingsGateway->getLifecycleLastRun();
|
|
}
|
|
}
|