Zum Hauptinhalt springen

Mitglieder

Wer die Konsole nutzen darf und was: Mitglieder mit ihren Rollen in einem Tab, die Rollen selbst im anderen. Eine Einladung gehört der Person, die sie nennt, und der letzte Eigentümer kann sich nicht selbst entfernen.

The members screen, Users tab
Members, the Users tab.
The members screen, Users tab, dark theme
Members, the Users tab.

Users

Everyone in the organisation, with their roles and when they joined. Inviting sends an invitation that belongs to the address it names: redeeming it requires signing in as that person, and a token with no address to check is refused rather than waved through. Invitations still pending sit in their own band above the grid, resendable and revocable. Removing a member is guarded by the last-owner rule: an organisation can never be left with nobody who can administer it.

A member opened from the roster
A member open: roles, joined, removal.
A member opened from the roster, dark theme
A member open: roles, joined, removal.

Roles

The roles tab
Roles: system roles stated, custom roles derived.
The roles tab, dark theme
Roles: system roles stated, custom roles derived.

Four system roles ship with every organisation: owner, admin, member and operator. A system role opens read-only, listing every permission it carries, so what a role grants is a fact to inspect rather than a sentence to trust. Custom roles are authored here too, picking exactly the product permissions they should carry, and what a role may delegate follows the delegation rule: an owner can hand on everything, an admin everything except billing and role authoring, and the other roles nothing.

Where this meets the API

On the wire the roster is the organisationMembers query and the caller's own permissions are myGrants (GraphQL reference); roles and invitations are administered through the shared accounts service the whole platform signs in with, which is why a member here is the same identity that holds API credentials elsewhere.