Skip to content

Organizations: join and leave #81

Description

@Adron

Part of #80 — Organizations parity gaps

/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.

Activity

  1. added
    parityClosing a gap against interlinedlist.com
    P3Niche or minor
    on Sep 15, 2026
  2. Adron commented on Sep 16, 2026

    @Adron
    MemberAuthor

    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/organizations is 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.

  3. added a commit that references this issue on Sep 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Niche or minorarea:organizationsOrganizationsparityClosing a gap against interlinedlist.com

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions