You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Organizations: roles and public/private visibility surfaced correctly #83
/help/organizations documents roles and public-vs-private organizations. The Android member
management should reflect what each role may actually do, and the detail screen should show
visibility.
Audit the member screen against the documented roles; hide actions the current user's role does
not permit rather than failing the call.
Show and (for permitted roles) edit organization visibility.
Tests: per-role action visibility.
Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.
Implemented in the PR above (branch issue/83-org-roles-visibility). Closing here — review and any follow-up happens on the PR.
The role matrix is taken verbatim from /help/organizations rather than invented, and #81's known gap (Edit/Delete offered to non-members) is closed.
Three real wire bugs were found and fixed along the way:
isPublic was serialised as a string on create and update. The server returns 500 {"error":"Internal server error"} for "isPublic":"false" and 200 for "isPublic":false — so organization visibility never round-tripped from the app at all.
The PUT echo omits userRole and memberCount, so mapping it straight through made the owner who had just edited the org look like a non-member, hiding the actions they had just used.
isSystem was not modelled, which is why Leave was being offered on "The Public".
One thing worth raising on the server side: the API does not appear to enforce these role rules on the member endpoints. A plain member POSTing to /members got a 500 (foreign-key failure), not a 403, and PUT/DELETE on a member returned 404 "User is not a member of this organization" rather than a permission error. The Android gating is therefore the practical protection, which is not where you want it.
Also captured but not implemented: member suspend (active) — the server requires role alongside it ({"active":false} alone returns 400 "Valid role (owner, admin, or member) is required").
Activity
Adron commentedon Sep 16, 2026
Implemented in the PR above (branch
issue/83-org-roles-visibility). Closing here — review and any follow-up happens on the PR.The role matrix is taken verbatim from
/help/organizationsrather than invented, and #81's known gap (Edit/Delete offered to non-members) is closed.Three real wire bugs were found and fixed along the way:
isPublicwas serialised as a string on create and update. The server returns500 {"error":"Internal server error"}for"isPublic":"false"and200for"isPublic":false— so organization visibility never round-tripped from the app at all.PUTecho omitsuserRoleandmemberCount, so mapping it straight through made the owner who had just edited the org look like a non-member, hiding the actions they had just used.isSystemwas not modelled, which is why Leave was being offered on "The Public".One thing worth raising on the server side: the API does not appear to enforce these role rules on the member endpoints. A plain member POSTing to
/membersgot a 500 (foreign-key failure), not a 403, and PUT/DELETE on a member returned404 "User is not a member of this organization"rather than a permission error. The Android gating is therefore the practical protection, which is not where you want it.Also captured but not implemented: member suspend (
active) — the server requiresrolealongside it ({"active":false}alone returns400 "Valid role (owner, admin, or member) is required").merge: #83 organization roles + visibility (PR)