- Shipped
- August 15, 2026 at 4:04 AM UTC
- Author
- Kamo
- Commit
- bc0bbae
An operator granted "Manage Platform Sounds" on the Platform Administrators page saw the Sounds tab — the console gates on the right — opened the upload dialog, and was told "Only the top-level organization's owners can add platform sounds." The console and the endpoint behind it disagreed about who counted. This service was deciding for itself. It now asks the shared PlatformRightsResolver, which is the component that exists precisely because more than one service enforces platform access from more than one identity source: SecurityService reads a *** session, this reads forwarded headers, and what must not differ is the ANSWER. Ownership still qualifies — the resolver treats an owner of the top-level organization as holding every platform right — so nobody who could do this before has lost it. The top-level-organization precondition lives in the resolver too, so a tenant member with a stray granted row still cannot reach it. God-mode ELIGIBILITY (GD) is deliberately not activation: both flags or neither, matching SecurityService exactly, since a caller admitted by one service and refused by the other is the whole bug. The System User is excluded here as it is there: it operates inside tenants and must never operate the platform. SecurityService's copy of this gate was corrected separately. Two services having to be fixed one at a time is the tell that this is a class, not an instance, so it comes with a ratchet: a file that reads isOrganizationOwner out of a session without naming PlatformRightsResolver now fails the build, and the sound upload specifically must name the right the console shows the tab for. Verified non-vacuous by reintroducing the old refusal and watching it fail. 52 tests, 1 failure — ImageResizeServiceTest, pre-existing at HEAD and unrelated (PNG expected, WebP produced). The Docker build runs -DskipTests, so the image still builds.