Roles & permissions
What each role may do, how that is enforced, and why you cannot switch roles yourself.
How a role is assigned
A role is set on the account when an administrator creates it, and it determines which application you see. There is no role switcher: an account is a teacher account or a student account, not both.
Where one person genuinely needs two roles — a head of department who also teaches — the answer is two accounts. Sessions are rotated on a role switch precisely so that the two cannot be conflated.
How permissions are enforced
Hiding a button is not a permission. Every rule below is applied on the server.
- At the route. Each endpoint declares which roles may call it. A student calling a teacher endpoint is rejected before any handler runs.
- At the repository. Every query is scoped by institution at the data boundary, so a valid token for one institution cannot read another’s rows.
- At the resource. Ownership is checked as well as role — a teacher may edit their own course, not a colleague’s.
Generating course content is restricted to teachers server-side, not merely absent from the student interface. The student-side generation surface was deliberately removed rather than hidden.
Permission reference
Guests
One surface is reachable without an account: an Open Quiz public link. A guest supplies an identity at the start of the attempt, sits the quiz — optionally proctored — and their result lands in the same quiz group as enrolled attempts, tagged as a guest. Guests never hold a session and can reach nothing else.