- Spegnimento
- 4 agosto 2026 alle ore 03:56 UTC
- Autore
- Kamo
- Impegno
- ac979dd
Organization.handlesPhi has existed as a column with no way to set it, so PhiTenantGuard has been enforcing a flag nobody could turn on. This is the missing half: GET/PUT /api/security/phi/tenant. Authority is god eligibility AND an active godModeActive toggle, never one. Eligibility alone is what left the platform's god gates dead until 2026-07-22; here it would let any god-eligible operator switch off a live tenant's modules with one unremarkable click. The target is always the caller's own session org — there is no organizationId parameter, so no crafted request can reach a tenant the caller is not already inside. phiEffectiveDate is stamped on first enable and never rewritten, including on a later disable/re-enable. It scopes the breach-assessment and retention windows, so moving it forward would quietly shrink the period under review, and an audit date the application can advance is not evidence. The audit row is written BEFORE the flag moves, and CONFIGURE fails closed, so a trail that cannot be written refuses the change and returns 503 rather than leaving a boundary that moved with no record of when. Denied attempts are recorded too. Every row carries identifiers and the transition only, never content. blockedModules is derived from PhiModule through PhiTenantGuard rather than listed, so the warning the UI shows cannot drift from what the guard enforces. No new repository package: OrganizationRepository is already in this service's @EnableJpaRepositories list, so there is nothing to add alongside this bean. Verified: 298 tests, 1 error — **************** EntityManager NPE, which is pre-existing (baseline at 7968a21: 281 tests, same 1 error). RepositoryScanCoverageTest and **************** both pass.