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
/help/organizations covers Joining organizations (browse public organizations and join) and Leaving an organization. Android can browse and create but not join or leave.
Determine the real contract for joining — POST /api/user/organizations is the likely candidate
but is undocumented in the spec; capture the live request before implementing.
Leave, with a confirmation, and correct behaviour for the last remaining owner.
Tests: join/leave round-trips; last-owner guard.
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 #109 (branch issue/81-org-join-leave). Closing here — review and any follow-up happens on the PR.
The open question in this issue is answered:POST /api/user/organizationsis join, not create-under-user. Body is {"organizationId":"<id>"}, returns 201 {"message":"Joined organization successfully","membership":{…}}, with 409 conflict when already a member.
There is no dedicated leave endpoint. Leaving is expressed as removing your own membership via DELETE /api/organizations/{id}/members/{yourUserId}. That works, but it means leave depends on SessionStore.userId being present — worth confirming whether a DELETE /api/user/organizations/{id} exists or is planned, since a members/me route would be sturdier.
Last-owner behaviour confirmed live: the server returns 400 {"error":"Cannot remove the last owner","code":"bad_request"}. The UI detects the case client-side and explains it without offering a destructive action, falling back to mapping that exact server error to the same explanation.
Also fixed along the way: GET /api/organizations/{id} reports membership as userRole, never role — the existing DTO read only role, so the detail screen's role was always null. And GET /api/organizations/{id}/members is members-only (403), so that request is now skipped for non-members rather than surfacing a permission error.
Note for #83: the detail overflow still offers Edit/Delete to non-members. Membership is now known, so gating them is a small change — but it is roles/visibility work, so it was left there.
Activity
Adron commentedon Sep 16, 2026
Implemented in #109 (branch
issue/81-org-join-leave). Closing here — review and any follow-up happens on the PR.The open question in this issue is answered:
POST /api/user/organizationsis join, not create-under-user. Body is{"organizationId":"<id>"}, returns201 {"message":"Joined organization successfully","membership":{…}}, with 409conflictwhen already a member.There is no dedicated leave endpoint. Leaving is expressed as removing your own membership via
DELETE /api/organizations/{id}/members/{yourUserId}. That works, but it means leave depends onSessionStore.userIdbeing present — worth confirming whether aDELETE /api/user/organizations/{id}exists or is planned, since amembers/meroute would be sturdier.Last-owner behaviour confirmed live: the server returns
400 {"error":"Cannot remove the last owner","code":"bad_request"}. The UI detects the case client-side and explains it without offering a destructive action, falling back to mapping that exact server error to the same explanation.Also fixed along the way:
GET /api/organizations/{id}reports membership asuserRole, neverrole— the existing DTO read onlyrole, so the detail screen's role was always null. AndGET /api/organizations/{id}/membersis members-only (403), so that request is now skipped for non-members rather than surfacing a permission error.Note for #83: the detail overflow still offers Edit/Delete to non-members. Membership is now known, so gating them is a small change — but it is roles/visibility work, so it was left there.
merge: #81 organization join/leave (PR #109)