School Scoping and Authorization

Kralis is a multi-school platform. The authenticated user’s school is the tenant boundary for normal application work.

Home school and active school

Most clients only work with one school at a time. The API exposes the current school context so a client does not need to invent or accept arbitrary school identifiers:

API value	Meaning	Client use
`authUser.school`	The authenticated account’s permanent home school	Use for account/profile identity and home-school information
`authSchool`	The school selected for the current authenticated request	Use for school-scoped screens, filters, labels, and follow-up operations
Object `school` fields	The school that owns a returned object	Use as display/context data; do not use it to broaden authorization

For an ordinary school user, the home and active schools are the same. Kralis support operators may have an internal support context that differs, but public clients must not treat that as a general multi-school capability or offer an arbitrary school switcher. The API still enforces the active school, permissions, object state, and any relationship-based restrictions on every operation. When a client needs the signed-in user’s own profile, use authUser. When it needs the school currently governing the request, use authSchool. Do not assume that a broad users query is a substitute for either value.

Client responsibilities

Do	Do not
Use `authSchool` for current school-scoped work	Ask the user to type an arbitrary school identifier
Use opaque IDs returned by the API	Guess IDs or build authorization from URL values
Use `authUser` for the signed-in account	Find the signed-in account by searching all users
Hide actions unavailable to the current role	Assume hiding a button replaces server authorization
Handle permission errors as expected outcomes	Retry a forbidden operation with another school ID
Refresh context after role or school changes	Cache authorization decisions indefinitely

Roles and relationships

Access may depend on more than a broad role. A teacher’s classes or subjects, a student’s class and section, an LMS enrollment, a CBT session’s eligibility, or a Classroom access grant can narrow what the user may see and do.

Authorization layers

Treat authorization as a sequence of independent gates:

Gate	What the API checks	Typical failure
Authentication	The account is authenticated and active	`Authentication credentials are missing or no longer valid.`
School actor	The permanent account belongs to the active school for tenant-authored work	`This action must be performed by a user belonging to the active school.`
Django permission	The user has the operation’s `app.action_model` permission through a group or explicit assignment	`You do not have permission to perform this action.`
Role gate	The operation accepts the account type, such as administrator/dean broadcast management or non-student CBT mutation	A role-specific forbidden error
Relationship scope	The record matches assigned classes, subjects, current class, ownership, enrollment, audience, or grant	A teacher-scope, ownership, or eligibility error
Business state	The academic year, term, publication, timing, or record state allows the action	A current-year, published, or state-validation error

Account flags, groups, and `role`

The user model has separate classification flags: is_student, is_teacher, is_dean, and is_admin. is_active controls whether the account can authenticate. Django’s is_staff and is_superuser are platform classifications. The exposed role field is a convenience value, resolved in this order: superuser, staff, admin, dean, teacher, then the fallback student. It is not a permission check, and a fallback student value does not prove that the account has a Student profile. GraphQL permission_required uses user.has_perm(). In the standard setup the permissions come from the matching Student, Teacher, Dean, or Admin group. An account can therefore have is_admin: true, authenticate successfully, and still be denied if it has no Admin group or explicit permission. When provisioning or repairing an account, update the classification, profile, school, active state, and group membership together. After a role or group change, refresh the viewer/session data in the client.

School and platform context

Normal school accounts have the same permanent and active school. Platform support operators are a special case: an active superuser assigned to the reserved Kralis platform school may select a support school. Public clients must still use authSchool/request_school and must not invent a school switcher. Author-owned operations additionally require a school-local actor; support activity is audited separately.

Teacher scope examples

SRMS teacher writes are limited to assigned class/subject context and the current academic year.
CBT teachers can use general or assigned test contexts and can see reusable questions/answers, but creating or changing class/subject-context content is checked against their assignments. Test ownership is also recognized.
LMS teachers can manage their own courses, or courses in an assigned subject and assigned/general class. Descendant content inherits course scope; enrollment operations also check the student’s current class.
Attendance queries and marking another student’s attendance are limited to students in a teacher’s assigned classes. Deletion is additionally protected by core.delete_attendance, which is not in the default Teacher bundle.
Student class movement is a school-leadership operation. Teachers may update permitted profile data and section information for students in their classes, but the API rejects a teacher attempt to change current_classe_id.

See Roles and Permissions for the full role matrix and the broadcast/Classroom distinctions.

IDs

Use IDs from authenticated responses for follow-up GraphQL operations. Do not derive authorization from a school acronym, name, slug, or a copied URL; the API applies the signed-in user’s school and role.

Diagnosing missing data

A globally privileged-looking account is not permission to mix schools in a public client. Render and operate within the school context authorized by the API.

​Home school and active school

​Client responsibilities

​Roles and relationships

​Authorization layers

​Account flags, groups, and role

​School and platform context

​Teacher scope examples

​IDs

​Diagnosing missing data

Home school and active school

Client responsibilities

Roles and relationships

Authorization layers

Account flags, groups, and `role`

School and platform context

Teacher scope examples

IDs

Diagnosing missing data