Skip to content

Organizations: roles and public/private visibility surfaced correctly #83

Description

@Adron

Part of #80 — Organizations parity gaps

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

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 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:

    1. 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.
    2. 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.
    3. 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").

  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