RBAC for schools: roles, permissions and scopes

Most software gives you three roles and hopes your institute is shaped like the one the developers imagined. It never is. The fix is not more roles; it is separating the two things that get conflated.

A permission is an act, not a person

A permission is a key like course.course.publish or finance.invoice.refund: module, resource, action. There are 272, each described for a school administrator rather than an engineer, because the person choosing them is not a developer.

A role is a named bundle of keys

Teacher, Academic Head, Finance Officer. Eleven editable templates ship, and each institute gets its own copies rather than sharing ours. The important part: nothing in the code reads a role’s name. A guard asks "does this person hold finance.invoice.refund?", never "is this person a Finance Officer?".

That is what lets you invent a role we never thought of — a Vice Principal who approves courses but not fees, a part-time counsellor who can add enquiries but not spend a seat — without waiting for us.

A scope is how far it reaches

• GLOBAL — the platform operator.
• TENANT — the whole institute.
• BRANCH or DEPARTMENT — one campus, one faculty.
• COURSE or BATCH — what they teach.
• RECORD — their own row, which is what a learner and a parent hold.

Why the frontend gating is not the security

Hiding a button is a courtesy, not a boundary. Every server route carries its own permission check or an explicit public marker, and a coverage check fails the build otherwise. If the interface hid a button and the server did not check, anybody with a browser console would find it in an afternoon.