Files
breadcrumb-the-shire/core/App/Container/Registrars/UserRegistrar.php

81 lines
5.9 KiB
PHP
Raw Normal View History

2026-03-04 15:56:58 +01:00
<?php
namespace MintyPHP\App\Container\Registrars;
use MintyPHP\App\AppContainer;
use MintyPHP\App\Container\ContainerRegistrar;
use MintyPHP\Repository\Access\UserRoleRepository;
use MintyPHP\Repository\Org\UserDepartmentRepository;
2026-03-05 11:17:42 +01:00
use MintyPHP\Repository\Tenant\UserTenantRepository;
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 MintyPHP\Repository\User\UserLifecyclePolicyDashboardRepository;
2026-03-04 15:56:58 +01:00
use MintyPHP\Repository\User\UserReadRepository;
use MintyPHP\Repository\User\UserWriteRepository;
use MintyPHP\Service\Auth\TenantSsoService;
use MintyPHP\Service\Branding\BrandingLogoService;
refactor(settings): remove global appearance settings — tenant is sole source Removes the global app_theme, app_theme_user and app_primary_color settings from the admin/settings area and the underlying service/cache/API/i18n/docs layers. The tenant columns (tenants.primary_color, default_theme, allow_user_theme) become the single source of truth for appearance. Branding helpers are tenant-only and fall back to a hardcoded 'light' theme with no brand color when no tenant context is available (login, error, pre-session pages). The APP_THEME env var is removed. Scope: - UI: Appearance tab gone from /admin/settings; tenant edit form drops the global-fallback color preview. - Service: SettingsAppGateway no longer exposes setting-backed accessors for theme/user-theme/primary-color. Theme catalog utilities (listThemes, isAllowedTheme, normalizeTheme, resolveDefaultTheme) stay and are used across Tenant / Auth / User flows; resolveDefaultTheme now hardcodes 'light' with a catalog fallback (no global/env lookup). - AdminSettingsService: buildPageData, sanitization, audit snapshot, apply step and cache payload are all stripped of the three keys. Dead helper applyAppPrimaryColor + normalizePrimaryColor removed. - Cache: SettingCacheService HOT_PATH_KEYS drops the three keys. - API: /settings (GET/PUT) and /settings/public (GET) no longer expose appearance fields; OpenAPI schemas pruned accordingly. - Audit redaction list shortened. - DB: db/init/init.sql seed rows removed. No migration for existing installs — legacy rows stay inert. - i18n + docs: setting.app_theme, setting.app_theme_user, setting.app_primary_color removed from de+en locales; reference and explanation docs updated. - Tests: covering tests for the removed methods pruned; ThemeResolutionTest rewritten for tenant-only semantics. One unrelated PHP-CS-Fixer issue in UserRegistrar.php cleaned up to keep QG-006 green. Workflow: .agents/runs/SETTINGS-APPEARANCE-TENANT-ONLY/ (gitignored). Gates: QG-001..003, QG-006, QG-008 all pass (1985 tests, 28764 assertions). Reviews: code, security, acceptance all pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-22 22:40:15 +02:00
use MintyPHP\Service\Tenant\TenantScopeService;
2026-03-04 15:56:58 +01:00
use MintyPHP\Service\User\UserAccessPdfService;
use MintyPHP\Service\User\UserAccessTemplateService;
use MintyPHP\Service\User\UserAccountService;
2026-03-05 11:17:42 +01:00
use MintyPHP\Service\User\UserApiWriteInputMapper;
2026-03-04 15:56:58 +01:00
use MintyPHP\Service\User\UserAssignmentService;
use MintyPHP\Service\User\UserAvatarService;
use MintyPHP\Service\User\UserDirectoryGateway;
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 MintyPHP\Service\User\UserLifecyclePolicyDashboardService;
2026-03-04 15:56:58 +01:00
use MintyPHP\Service\User\UserLifecycleRestoreService;
use MintyPHP\Service\User\UserLifecycleService;
use MintyPHP\Service\User\UserPasswordPolicyService;
use MintyPHP\Service\User\UserPasswordService;
2026-04-22 15:49:10 +02:00
use MintyPHP\Service\User\UserProfileViewService;
2026-03-04 15:56:58 +01:00
use MintyPHP\Service\User\UserRepositoryFactory;
use MintyPHP\Service\User\UserServicesFactory;
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;
2026-03-04 15:56:58 +01:00
use MintyPHP\Service\User\UserTenantContextService;
final class UserRegistrar implements ContainerRegistrar
{
public function register(AppContainer $container): void
{
$container->set(UserSettingsGateway::class, static fn (AppContainer $c): UserSettingsGateway => $c->get(UserServicesFactory::class)->createUserSettingsGateway());
2026-03-04 15:56:58 +01:00
$container->set(UserAccountService::class, static fn (AppContainer $c): UserAccountService => $c->get(UserServicesFactory::class)->createUserAccountService());
$container->set(UserAssignmentService::class, static fn (AppContainer $c): UserAssignmentService => $c->get(UserServicesFactory::class)->createUserAssignmentService());
$container->set(UserPasswordService::class, static fn (AppContainer $c): UserPasswordService => $c->get(UserServicesFactory::class)->createUserPasswordService());
$container->set(UserAvatarService::class, static fn (AppContainer $c): UserAvatarService => $c->get(UserServicesFactory::class)->createUserAvatarService());
$container->set(UserDirectoryGateway::class, static fn (AppContainer $c): UserDirectoryGateway => $c->get(UserServicesFactory::class)->createUserDirectoryGateway());
$container->set(UserAccessTemplateService::class, static fn (AppContainer $c): UserAccessTemplateService => new UserAccessTemplateService(
$c->get(TenantSsoService::class),
$c->get(UserDirectoryGateway::class),
$c->get(UserTenantRepository::class)
));
$container->set(UserAccessPdfService::class, static fn (AppContainer $c): UserAccessPdfService => new UserAccessPdfService(
$c->get(UserAccessTemplateService::class),
feat(tenant): per-theme logos + file-upload + button UI polish Replace the single tenant avatar with a pair of theme-scoped brand logos. Render only the theme-matching <img> server-side and swap src on theme toggle via a JS hook — no reload, no double request, no CSS tricks. Tenant logos - TenantLogoService (ImageUploadTrait) with theme whitelist and per-theme storage storage/tenants/{uuid}/logo/{light|dark}/, SIZES 128/256/512 - Public serving endpoint auth/tenant-logo-file so login can show the logo pre-auth; matching authenticated admin preview endpoint - appTenantLogoUrl(?size, ?theme) with 4-step fallback cascade; PDF + mail always request 'light' - Admin tenant edit: avatar block replaced by "Tenant logos" details block inside the Master-data tab, two side-by-side slots via Pico .grid with the core app-file-upload partial - Policy rename ABILITY_ADMIN_TENANTS_AVATAR_VIEW -> LOGO_VIEW, action routes logo / logo-delete / logo-file with theme body/query param - API endpoint path kept (backward compat), internals on new service - CLI tenant:logo-migrate-avatars moves legacy avatar/ -> logo/light/ idempotently (--dry-run, --yes, --cleanup) - i18n "Tenant image" removed, 12 new keys synced across de/en File upload component - Full-width preview + filename/actions below (3D stack layout) - Fixed 16:9 aspect ratio with 1rem inner padding for consistent preview size across any logo aspect - Transparency checker pattern as background so black logos stay visible on dark mode and white logos on light mode - form="" + deleteFormId support so the partial works with barrier forms inside another form Buttons - width:100% dropped from button[type="submit"]; scoped back via .login-main for the auth-flow primary CTA - .outline base rule now tints background via color-mix of --app-color so secondary/primary/danger outlines all gain a subtle surface - .outline.secondary restyled Stripe-style in both themes: solid white chip with soft shadow in light, solid elevated dark chip with white text in dark; neutral border replaces role-colored border - .app-action-success/.app-action-danger outlines get color-mix bg + theme-aware outline-text tokens for stronger contrast - Filled .primary/.app-action-success/.app-action-danger get raised box-shadow (inset highlight + drop) — opt-in via class so chrome buttons stay flat - Dropped the legacy .secondary utility that was clobbering the custom-property cascade with a hardcoded muted color Theme swap - Logo img carries data-src-light + data-src-dark; theme-toggle JS swaps src when data-theme changes, keeping the topbar/login logo in sync without a page reload Quality gates: PHPUnit (2045), PHPStan L5, CS-Fixer, docs link/drift, codex skills sync — all green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-24 20:25:53 +02:00
$c->get(BrandingLogoService::class),
$c->get(\MintyPHP\Service\Tenant\TenantLogoService::class)
2026-03-04 15:56:58 +01:00
));
$container->set(UserTenantContextService::class, static fn (AppContainer $c): UserTenantContextService => $c->get(UserServicesFactory::class)->createUserTenantContextService());
$container->set(UserLifecycleService::class, static fn (AppContainer $c): UserLifecycleService => $c->get(UserServicesFactory::class)->createUserLifecycleService());
$container->set(UserPasswordPolicyService::class, static fn (AppContainer $c): UserPasswordPolicyService => $c->get(UserServicesFactory::class)->createUserPasswordPolicyService());
$container->set(UserLifecycleRestoreService::class, static fn (AppContainer $c): UserLifecycleRestoreService => $c->get(UserServicesFactory::class)->createUserLifecycleRestoreService());
$container->set(UserApiWriteInputMapper::class, static fn (AppContainer $c): UserApiWriteInputMapper => new UserApiWriteInputMapper(
$c->get(\MintyPHP\Service\Tenant\TenantService::class),
$c->get(\MintyPHP\Service\Access\RoleService::class),
$c->get(\MintyPHP\Service\Org\DepartmentService::class)
));
$container->set(UserReadRepository::class, static fn (AppContainer $c): UserReadRepository => $c->get(UserRepositoryFactory::class)->createUserReadRepository());
$container->set(UserWriteRepository::class, static fn (AppContainer $c): UserWriteRepository => $c->get(UserRepositoryFactory::class)->createUserWriteRepository());
$container->set(UserTenantRepository::class, static fn (AppContainer $c): UserTenantRepository => $c->get(UserRepositoryFactory::class)->createUserTenantRepository());
$container->set(UserRoleRepository::class, static fn (AppContainer $c): UserRoleRepository => $c->get(UserRepositoryFactory::class)->createUserRoleRepository());
$container->set(UserDepartmentRepository::class, static fn (AppContainer $c): UserDepartmentRepository => $c->get(UserRepositoryFactory::class)->createUserDepartmentRepository());
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
$container->set(UserLifecyclePolicyDashboardRepository::class, static fn (AppContainer $c): UserLifecyclePolicyDashboardRepository => $c->get(UserRepositoryFactory::class)->createUserLifecyclePolicyDashboardRepository());
$container->set(UserLifecyclePolicyDashboardService::class, static fn (AppContainer $c): UserLifecyclePolicyDashboardService => new 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
$c->get(UserLifecyclePolicyDashboardRepository::class),
$c->get(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
));
2026-04-22 15:49:10 +02:00
$container->set(UserProfileViewService::class, static fn (AppContainer $c): UserProfileViewService => new UserProfileViewService(
$c->get(UserAccountService::class),
$c->get(UserAssignmentService::class),
$c->get(TenantScopeService::class),
$c->get(UserAvatarService::class)
));
2026-03-04 15:56:58 +01:00
}
}