#Members
Backend Phase 4 is complete (2026-10-03, by Pair 1), so members now have V8 rules V8 requirement — screen spec on FE: Organization & Members screens. The endpoints are still not published Missing. The V7 detail below stays as background.
Also settled by Phase 4: every invite must be accepted, including by existing users (closes D-9, as we recommended); invitation links expire after 7 days (our recommendation); invites can be resent and cancelled (V7 had no dedicated endpoints); leave organization now exists (V7 had none); the owner can't be changed, removed or assigned; and shared servers stay (4.6), which reverses our D-8 recommendation to drop them.
#Member list
V7 GET /organizations/{org}/members (search by name/email): each member with user (id, name, email, avatar) and roles. Pending invitations come back as rows with invitedUser.email and a gravatar, and no user. V7 only
| Column | Source |
|---|---|
| Name + avatar | User (or email for pending) |
| User / invitation | |
| Designation | organization_members.designation (free text, required in V7) |
| Role(s) | member_role (several possible) |
| Status | Derived: user_id set → Active · user_id null + token → Pending. V7 stores no status column Missing |
| Joined | created_at |
| Actions | Change role, Remove / Cancel invitation |
Concept from the demo Demo UI only: KPI strip (Active, Pending, Owners), filters (role), sort (name, role, recently added), empty state "Bring your first teammate in".
#Actions
| Action | V7 behaviour | V8 |
|---|---|---|
| Invite | POST members with email, designation, role[]. Existing user: added immediately ("added in … organization") + "joined organization" email. Error if already a member ("User is already in a organization" / "in a share-server"). Unknown email: a member row with invitation_token + invitation email. Audit "Organization Invite" | Missing |
| Pending invitation | Member row without a user | Missing |
| Accept invitation | The invitee registers with invitation_token, or sets a password through POST /user/password-set/{token}. The membership then gets the user (V8 requirement 2.6) | Missing |
| Resend invitation | No dedicated endpoint. Inviting the same email again re-sends the email for the existing pending row | Missing (dedicated endpoint recommended) |
| Cancel invitation | No dedicated endpoint. Deleting the member row cancels it | Missing |
| Change role | PATCH members/{member}/assign-role with designation, role[] | Missing |
| Remove member | DELETE members/{member}. Owner only. Can't remove yourself. Can't remove shared-server members from here | Missing |
| Leave organization | Not in V7 | Yes V8 requirement Phase 4 (4.4) |
| Invitation expiry | Not in V7 (tokens never expire) | 7 days V8 requirement Phase 4 (4.3) |
#Statuses (proposed for V8)
| Status | Meaning |
|---|---|
pending | Invited, not accepted. Can be resent or cancelled |
active | Member with roles |
expired | Invitation older than the expiry Assumption |
removed | Kept only in the audit log |
#Rules
- At least one Owner always exists. The owner can't be removed or demoted by others.
- A member has exactly one role V8 requirement Phase 4 (4.4). (V7 validated
roleas a required array and allowed several.) - Every action writes an audit entry (actor, member email, roles before/after).
- Plan limit on members: none in V7 (member count isn't a plan limit). Confirmed