- Shipped
- September 5, 2026 at 3:06 PM UTC
- Author
- Kamo
- Commit
- c329628
Authored in a concurrent session on this machine and committed here at the user's request; recorded so the provenance is not guessed at later. The user account is the PERSON, and editing it used to require the current organization to own the account. That was wrong twice over. An account's owner is a person, not an organization, so the condition answered a question about administrators and was being applied to somebody editing their own details. And it was a dead end in practice: the platform provides the account for almost every tenant member — 77 of 141 memberships on 2026-09-04 — and 37 of those people are not members of the organization that owns their account at all, so no workspace existed in which they could ever edit their own preferred name, website or links. The gate is now the owner, a god-eligible operator, the System User, or a holder of the platform rights that administer user accounts (MANAGE_USERS / SYSTEM_USER — the Users tab on /account). The top-level-organization precondition rides along rather than being checked separately, because a session inside a tenant resolves no platform right at all. Tenant rights stay deliberately absent. MANAGE_MEMBERS and MANAGE_MEMBER_SECURITY do not reach the user account: a tenant administrator can edit their own organization's security models, so a tenant holding either could grant itself the ability to rewrite the identity every other organization that person belongs to can see. That is the same reasoning that keeps them off the password. With the owning-org condition gone, the "your account is managed elsewhere" banner and the cross-org sign-in link it carried have nothing left to explain, so they and their plumbing are removed.