Skip to main content
Kralis is strongly role-aware. The app does not present every workflow to every user in the same way. There are two separate concepts:
  • account classification, stored in fields such as is_teacher, is_dean, is_student, and is_admin;
  • authorization, supplied by Django group permissions and feature-specific scope.
An account can have the expected flag and still be denied if its matching group or permission is missing. See Roles and Permissions for the complete model. The most important public roles are:
  • admin
  • dean
  • teacher
  • student

​
Capabilities

Role-aware access in Kralis supports:
  • different navigation by user role
  • different workflow access by user role
  • school-setup dependence for daily operations
  • student-facing self-service where enabled

​
Why role documentation matters

Many support and onboarding issues are not product failures at all. They are the result of:
  • expecting a workflow that belongs to another role
  • missing school setup
  • missing class, section, or subject assignment
  • missing permissions or incorrect current school context

​
Role summary

  • admins usually manage school settings, structure, access PINs, users, and the broadest operational workflows
  • deans usually share many academic and school-operations workflows with admins
  • teachers typically work in teaching-facing modules such as results, tests, LMS, Classroom, and attendance
  • students mainly consume their own results, tests, courses, attendance context, live classes, and fee information
Use the role pages in this section to understand the expected daily experience. Teachers cannot move a student’s current_classe_id. Deans and administrators perform class placement changes. Teacher section/profile updates remain subject to the assigned-class check.