Plan 3 (#1303) lifted Org membership from per-user to per-tenant, and
40fdb978 pinned the org's owner tenant in DB as organizations.owner_tenant_id.
The OrganizationSettingsModal members list, however, still decided
"which row is the owner" by comparing member.user_id against
orgInfo.owner_id. After Plan 3 the members list is keyed on tenant_id,
so the user-id check is structurally wrong: the representative user of
the owner tenant happens to be the owner today, but if that user is
moved to another tenant — or a different user of the owner tenant
becomes the representative — the modal would either lose the "(owner)"
tag, or re-tag a non-owner row, and would offer the role-select /
remove-button affordances on what is in fact the owner tenant row.
This change:
- Adds OwnerTenantID to OrganizationResponse and populates it in
toOrgResponse from the persisted column. IsOwner now compares the
caller's current tenant against owner_tenant_id (with a user-id
fallback for legacy rows where owner_tenant_id == 0).
- Adds owner_tenant_id to the frontend Organization type and a small
isOwnerMember(member) helper in OrganizationSettingsModal, which
tenant-matches by default and falls back to user-id only on
pre-000046 rows. The role <select>, role tag suffix, and the
delete button on member rows now all use the helper.
The "is-me" CSS class and the me-tag in the member name still match
on user_id — that one really is a per-user marker ("this row's user is
me, the signed-in user").
wizardchen
cf6c28fe7e