#FE: Organization & Members screens (from backend Phase 4)
Frontend spec for backend Phase 4: Organization & Members — requirements complete 2026-10-03, written by Pair 1, not built. V8 requirement This is the phase the frontend had been waiting for (old gap D-25, now closed), and it settles three questions the frontend had open: permission levels (D-7), whether invites must be accepted (D-9) and whether shared servers stay (D-8).
Switcher
top bar — my organizations, default marked, create, manage
Organizations
list, create, view, rename, set default, delete
Members
list + search, invite, change role, remove, leave
Roles
Owner and Admin fixed, custom roles with view / manage
Share server
one server shared with one person, by invite
Ownership transfer
owner hands the organization to an existing member
Activity
organization, member, role, share and transfer actions
i18n namespaces: org.*, org.members.*, org.roles.*, org.share.*, org.transfer.*, org.activity.*, org.errors.*.
#A. Organizations
| # | Feature | Screen / control | Rules from the backend doc | Frontend notes |
|---|---|---|---|---|
| 4.1 | Create, list, view, update, set default | List page + create dialog + settings. Switcher in the top bar | The creator is the owner. The first organization becomes the default. A letter avatar is generated when there is no logo. Conflict D-2 (Bhavik, 2026-10-05): the user's first organization is created by the backend at sign-up, so they never create it themselves — the backend doc still says organizations are not auto-created | Mark the default in the list and the switcher ("Default"). "Set as default" is a one-click action with an optimistic toggle. Render the letter avatar on the frontend from the name's first letter when the API sends no logo, so lists never show a gap. Because the first organization arrives ready-made, the create dialog is only ever for extra organizations — and the list is never empty on a fresh account, so the empty state is a fallback, not the normal first screen |
| 4.2 | Delete organization | Danger zone, type-to-confirm (type the name) | Owner only. Never the default organization (Bhavik, 2026-10-05 10:24 — the backend's Phase 4 rule said the same, and this makes it absolute), and not while it has servers | Disable the button with the reason instead of failing after the click: "Remove or move its N servers first". On the default organization the button is permanently off — not "make another one default first", because the default is created at sign-up (D-2) and every account always has one. So the delete flow only ever applies to the extra organizations a user made. Still show the backend's refusal if it disagrees |
#B. Members & invitations
| # | Feature | Screen / control | Rules | Frontend notes |
|---|---|---|---|---|
| 4.3 | Invite members | "Invite member" dialog: email, designation, role | Every invite must be accepted — including by existing users. Links expire after 7 days. Invites can be resent or cancelled | One role picker, not a multi-select (see 4.4). Pending rows show "expires in N days" and expire visibly after 7 days. Resend and Cancel are per row; Cancel is a confirm dialog |
| 4.4 | Manage members | List + search. Row actions: change role, remove, leave | One role per member. The owner can't be changed, removed or assigned | The owner's row has no actions at all (not even disabled ones that look clickable). "Leave organization" is in the user's own row, with a confirm dialog that says what they lose |
| 4.6 | Share server | "Share server" from a server, by invite | Access to one server through an accepted invite. A shared user can never create, delete or share that server | Shared people appear in a separate list from members (they are not organization members). The server page hides create / delete / share for them, and the invite dialog states the limit in one line |
#C. Roles
| # | Feature | Screen / control | Rules | Frontend notes |
|---|---|---|---|---|
| 4.5 | Roles | List + create/edit dialog with the permission matrix | Owner and Admin are fixed. Custom roles use view / manage permissions. Parent permissions are ticked automatically. A role can't be deleted while it has members | Owner and Admin open read-only. In the matrix, ticking a child auto-ticks its parent and says so (a short line, not a toast per click). Delete is disabled for a role in use, with "N members use this role — move them first" |
#D. Ownership transfer (new in V8)
Backend item 4.7. This is the most delicate flow in the phase, and it has two sides.
Owner startsPicks an existing memberConfirms with own password (or email code) + own 2FAInvite sentNew owner accepts within 48 hNew owner confirms with own password + own 2FATransfer doneOld owner becomes admin
| Rule from the backend doc | What the frontend must do |
|---|---|
| Owner only, and only to an existing member | The action appears only for the owner. The picker lists current members only — no free-text email |
| Both sides confirm with their own password (or email code) plus their own 2FA if it is on | Two separate confirm dialogs, one per person. Reuse the same step pattern as 2FA at login. Never ask one person for the other's credentials |
| Accept within 48 h | Show "expires in N hours" on the pending transfer, for both people, and an expired state with "start again" |
| The old owner becomes admin | Say this plainly before starting, and again in the success message — it is the part people get wrong |
| Blocked if there are unpaid charges, or the new owner's plan doesn't fit | Show the backend's reason and a link to fix it (pay the balance / the member needs a bigger plan). Check before showing the final button where the API allows it |
| Moving server subscriptions on transfer is left to the billing phase | Don't promise anything about subscriptions in this flow yet |
States: no transfer · pending (I started it) · pending (waiting for me to accept) · expired · done · blocked with a reason.
#E. Activity
Backend item 4.8: the organization activity log covers organization, member, role, share and transfer actions. This is the organization-level log on the Audit log page — different from the account activity in Phase 3 (3.12). V8 requirement
#Not in this phase (backend doc)
- The permission list and seeder are a separate step — so the exact permission names are still not published. The matrix must be built from the API's catalog, never from a hard-coded list.
- Delete permission and hosting users wait on open questions.
- Moving server subscriptions on ownership transfer → billing phase.
#Existing users
V7 organizations, members, roles and shared servers carry over at migration. The screens must cope with imported data from the first load: members holding one role (V7 allowed several — see the conflict below), custom roles with migrated permissions, and shared-server people who are not members.