Who can do what inside an organisation. This table is checked against the code that enforces authorization, on every build.
| Capability | Owner | Admin | Trainer |
|---|---|---|---|
Close the organisationorg.close | yes | no | no |
Manage billing and the subscriptionbilling.manage | yes | yes | no |
Change organisation settingsorg.manage | yes | yes | no |
Change a role, remove a membermembers.manage | yes | yes | no |
Invite membersmembers.invite | yes | yes | no |
See the member listmembers.read | yes | yes | no |
See every session in the organisationsession.read.any | yes | yes | no |
Create a sessionsession.create | yes | yes | yes |
See their own sessionssession.read.own | yes | yes | yes |
Edit their own sessionssession.update.own | yes | yes | yes |
Create, publish and test labslab.manage | yes | yes | yes |
Roles are changed under Administration > Members, by an owner or an admin.
One capability separates them: closing the organisation. An admin can do everything else, including billing and changing roles. Closing suspends the organisation and cancels the subscription; it is reversible, but not by someone still inside it.
A learner is not a member of the organisation. Their rights come from the session that invited them and end with it, so they do not appear in this table and none of these capabilities is available to them.
It is not written by hand. A test reads this table and compares it, capability by capability, against the one that actually decides authorization on the server. A divergence fails the build before it reaches production.