Who can do what
Three roles in a group, and an owner who is not a role. This table is built from the application's own code: it cannot fall behind it.
The matrix
| Capability | Group admin | Organiser | Member |
|---|---|---|---|
| Edit the group (name, logo, visibility) | ✅ | — | — |
| Delete the group | ✅ | — | — |
| Turn the group into an organisation | ✅ | — | — |
| Fill in legal identity and billing | ✅ | — | — |
| Invite and add members | ✅ | — | — |
| Remove a member | ✅ | — | — |
| Change a member's role | ✅ | — | — |
| Accept or reject join requests | ✅ | — | — |
| Request a trial or a subscription | ✅ | — | — |
| Create a tournament in the group | ✅ | ✅ | — |
| Run tournaments (players, schedule, scores) | ✅ | ✅ | — |
| Take part in tournaments | ✅ | ✅ | ✅ |
| View the group's statistics | ✅ | ✅ | ✅ |
The owner
The owner is absent from this table because the owner is not granted: it is observed. It is the group's creator. They cannot be removed, their role cannot be changed, and they appoint the first administrators.
Why an « organiser » role
Before it existed, letting someone run a tournament meant making them an administrator — and thereby handing them memberships, roles and billing in the same gesture. The organiser draws exactly that line: they make tournaments live, they do not touch the structure.
What this table does not say
A real authorisation also accounts for three more things: the global administrator, the parent organisation's administrator for an internal group, and delegation to members when it is switched on and the product allows it. This table is a faithful summary, not a complete specification.