Roles and Permissions

Kralis authorization is the combination of several checks. A successful login only proves that the account is authenticated; it does not grant every operation in the school. An operation is allowed only when all applicable checks pass:

the account is authenticated and active;
the request is inside the active school;
the account has the required Django permission, such as core.view_student or srms.change_entry;
the account’s role and relationship allow the specific record;
the academic period, publication state, ownership, and other model rules allow the action.

Account flags

The user model stores role classifications as independent boolean fields. They are not interchangeable with permissions.

Field	Meaning	Important behavior
`is_active`	Account may authenticate	An inactive account cannot use normal authenticated operations.
`is_student`	Account has student identity	Student-specific ownership and current-class rules apply when a student profile exists.
`is_teacher`	Account has teacher identity	Assigned classes and subjects narrow teacher operations in teaching modules.
`is_dean`	Account has dean or school-leadership identity	The built-in Dean group provides broad school-operation permissions.
`is_admin`	Account has school-administrator identity	The built-in Admin group provides the broadest school-management bundle.
`is_staff`	Django/platform staff classification	This is a privileged platform classification, not a substitute for school-admin setup.
`is_superuser`	Django superuser classification	A platform superuser is recognized as a support operator only when assigned to the reserved Kralis platform school.

The API exposes a convenient role string, but it is a simplified classification. Its resolution order is:

is_superuser → admin
is_staff → admin
is_admin → admin
is_dean → dean
is_teacher → teacher
otherwise → student

Keep role flags mutually exclusive for normal school accounts. A general account with none of the school-role flags can still receive the fallback role: "student"; that value does not by itself prove that a Student profile exists. Client code should use the actual profile and permissions for authorization decisions.

Groups and Django permissions

Kralis creates built-in Django groups and assigns permission bundles to them:

Group	Bundle
`Student`	Baseline read permissions for school records and self-service features, plus student-facing writes such as submitting CBT responses, enrollment progress, attendance attempts, Classroom collaboration, and fee payments.
`Teacher`	The Student bundle plus teaching and academic permissions: SRMS results, entries, annuals, CBT questions, answers, tests, test questions, LMS content, Classroom teaching operations, and teacher/student update permissions.
`Dean`	The Teacher bundle plus school structure, users, teachers, subjects, classes, sections, broadcasts, fees, attendance correction, and integration-identifier management.
`Admin`	The Dean bundle plus school settings, academic year and term administration, promotions, Access PIN inventory, and school subscription/payment/invoice/checkout visibility.
`Staff`	The Admin permission bundle for platform staff accounts; platform access is still governed by the platform-school rules.

The exact permission names are standard Django codenames in the form:

<app_label>.<action>_<model>

Examples include:

core.view_student
core.change_student
core.add_broadcast
srms.change_entry
cbt.add_test
lms.change_course
classroom.change_classroomevent
fees.add_fee

view, add, change, and delete are separate permissions. A user may be able to view a record without being able to change or delete it.

Role flags do not grant permissions by themselves

GraphQL operations protected with permission_required call Django has_perm(). In the normal setup, has_perm() succeeds because the account belongs to the corresponding group or has an explicitly assigned permission. Therefore, an account with is_admin: true but no Admin group can authenticate and still fail every protected operation. When a role appears correct but the API returns:

You do not have permission to perform this action.

check, in this order:

is_active;
the account’s school and active request school;
the expected role flag;
membership in the matching Student, Teacher, Dean, or Admin group;
the specific permission required by the operation.

The browser may hide actions based on role, but the API remains the authority. Adding a button or navigating directly to a page does not bypass a missing permission.

What each role can access

These are the default product boundaries. A feature can impose a narrower relationship or state rule.

Area	Student	Teacher	Dean	Admin / platform operator
Own account	View and update permitted profile/security data	View and update permitted profile/security data	Same	Same, plus management views where permitted
Student records	Own private linked records	View school students; update biodata for students in assigned classes	School-wide management	School-wide management
Move a student to another class	No	No	Yes	Yes
Change a student’s section	No	Allowed for an assigned student; the API still rejects changing `current_classe_id`	Yes	Yes
Years, terms, classes, sections, subjects	Read only where exposed	Teaching context; selectors may be narrowed to assigned records	Manage according to permissions	Manage, including year and term administration
SRMS	Own results and records	Assigned teaching workflows; teacher writes are current-year and assigned-class/subject scoped	School-wide result operations	School-wide result operations
CBT	Published tests eligible for the current class/general audience; own attempts and responses; reusable question-bank study where the query permission is exposed	Assigned/general or teacher-owned tests; school-wide reusable question and answer study; scoped creation and mutations	School-wide CBT operations	School-wide CBT operations
LMS	Enrolled courses and own progress	Own or assigned-scope courses; content and permitted enrollments	School-wide LMS operations	School-wide LMS operations
Attendance	Own attendance and summaries	Own attendance plus attendance queries and marking for students in assigned classes; correction/deletion still requires the matching permission	School-wide attendance operations	School-wide attendance operations
Classroom	Events, rooms, recordings, whiteboards, and groups visible through audience or grants	Events and objects visible through audience, grants, ownership, or event role; host/moderator actions require the effective event role	School-wide event moderation as a school administrator	School-wide event moderation and policy access
Fees	Own assignments, invoices, and payments	No default school-wide fee management	School-wide fee management	School-wide fee and billing access according to the operation
Broadcasts	Current broadcasts targeted to the user	Current broadcasts targeted to the user	Create, view, update, and delete school broadcasts	Create, view, update, and delete school broadcasts
Access PINs	No management	No management	No default management permission	Create, update, and delete according to permissions
Integration identifiers	No management	No management	Create, update, and delete school identifiers	Same, according to permissions

Feature-specific teacher scope

Teacher access is relationship-based rather than simply “all or nothing.” The relevant teacher profile assignments are the source of scope.

SRMS

Teachers work against assigned classes and subjects in the teaching UI.
Teacher mutations for results, entries, annuals, remarks, enrollment, and related SRMS records reject an unassigned class or subject.
Teacher SRMS mutations are restricted to the current academic year. Deans and admins handle historical-year corrections.
A teacher may not change a student’s current class. Section changes are separate from class placement and may be allowed when the student is in the teacher’s assigned class.

CBT

A test is visible to a teacher when it is general, matches an assigned class/subject, or was created by that teacher.
A student sees published tests for the student’s current class or general tests.
A student’s test session and response access also checks the student’s current class and the test’s class/subject context.
Questions and answers are reusable school content for study and reuse when the account has the view permissions. Their class and subject fields are grouping/display context, but when a teacher creates or mutates content with class/subject context, the supplied context must be assigned to that teacher.

LMS

A teacher can manage their own courses.
A teacher can manage another course only when its subject is assigned to them and its class is either assigned to them or general.
Course modules, lessons, and units inherit the course scope.
Enrollment and progress management additionally requires the learner to be in one of the teacher’s assigned classes.

Broadcast visibility

Broadcast management and broadcast delivery are different operations:

broadCasts is the management list and is restricted to administrators and deans with core.view_broadcast.
createBroadCast, updateBroadCast, and deleteBroadCast require the matching add/change/delete permission and the administrator/dean management role.
userBroadCasts is the delivery list. It returns current broadcasts targeted to the signed-in user, group, class, subject, course, or school audience. A teacher or student may receive a broadcast without being allowed to manage broadcasts.

Classroom roles are object-specific

Classroom event roles do not replace the account role. The effective event role can be:

host — normally the event creator or an explicit host grant;
moderator — a school administrator/dean or explicit moderator grant;
presenter — an explicit presenter grant;
participant — a matching audience or grant;
observer — an explicit observer grant.

When more than one source applies, the strongest event role wins. Draft events are visible only to users who can manage them; published/live event visibility is still based on audience, grants, ownership, and school context.

Permission troubleshooting

Use the failure message to identify the layer:

Symptom	Usually means
Authentication credentials are missing or invalid	No active authenticated session or an invalid/expired token
This action must be performed by a user belonging to the active school	The permanent account school and active request school do not match for an author-owned operation
You do not have permission to perform this action	Missing Django permission, group, or broad role gate
Teachers can only … assigned classes/subjects	The permission exists, but the requested object is outside the teacher relationship scope
Current-year-only or published/eligible error	The object state or academic-period rule rejected the operation

For custom clients, handle forbidden results as expected authorization outcomes and refresh viewer/authSchool after an account, role, group, or school-context change. See School Scoping and Authorization and Authentication for the request lifecycle.

​Account flags

​Groups and Django permissions

​Role flags do not grant permissions by themselves

​What each role can access

​Feature-specific teacher scope

​SRMS

​CBT

​LMS

​Broadcast visibility

​Classroom roles are object-specific

​Permission troubleshooting