😎Data Model Tenets

To maintain the data integrity and ascertain the signals and utility functions work as expected, these points ought to be followed. They are the facts/points/structure that govern the application logic, data model and its relationships.

Implementation details are available in the codebase via docstrings and comments and also more intuitively at /admin/doc endpoint (auth required).

SRMS

Kralis Student Result Management System

• A year ought to be created first before any other resource.

• A year is made up of three terms. Every year has three terms.

• A classe lasts through three terms and exists only within a year.

• Three are classes options enum. A student can be in all or some of them.

• A student can be in only one classe in a year.

• The highest classe a student can be until the student account is rendered inactive automatically is SS3.

• When a student account is rendered inactive either automatically or via the dashboard, new result won't be created for the student.

• A result is created any time there is a new term within a year and class.

• A result can have multiple entries. These entries are subjects the student is taking.

• An entry is tied to a particular result and a particular subject.

• A result is tied to a particular student, in a particular year, classe and term.

• A year's result is collected together into an Annual.

• There can only be one annual in a year.

• A result is also created by a teacher when the teacher tries to fetch a scoresheet for a year, term, subject and class. Results are fetched or created for all students who match the criterion. However, this is limited to students whose current classe matches the classe provided by the teacher and students who take the teacher's subject (that is student that have the subject either added to their result or the subject is part of their current classe general subject).

• A result is associated with multiple entries, these entries are subjects and are created via signals or when the entry is queried and the students' result falls within that criteria.

• This specific subject of a student can created via Entry by choosing the subject and result. The subject is added via the Subject model. Hence a result entry is tied to a particular result and subject.

• An entry is a subject taken by a student.

• An Annual Entry is a sum of the results entries (three terms) divided by the number of result the subject exists in across the terms.

• Student credentials get updated when a new student instance is created and during classe transitions.

• Student usernames are generated based on the SCHOOL_NAME_ACRONYM-CURRENT_YEAR-CURRENT_CLASS-STUDENT_ID

• Student Passwords are stored based on their hashed username, this is set as the default password. But when the student wants to log in, a password is set for the student based on the password pool. In cases of password reset, as a result of loss of password, the student password could be reset based on the hash of their username or a new password could be created for the student in the Password Pool.

• A student can have multiple passwords in the password pool, but the last one that is assigned to the student becomes the current working one. A student can't use the password used by another.

• This achieves a shared password pool model; hence, passwords are shared to student from the pool and a password from the pool gets tied to a student when used for the first time, such password can't be reused by another.

• When creating Students in the frontend/admin dashboard, just add any random username and password in the fields, the system will assign a unique username and password to the student before being saved, hence your random inputs will be overridden. This happens only during initial student creation. Another time it gets changed is during classe promotions.

• A Student account is considered unique during creation from the management command by the first name, last name and current classe fields. If there are students with the same names in the same class, one of their accounts will have to be created from the frontend/admin dashboard, after which the system will assign a unique username to the student, satisfying the student's account uniqueness.

• Same also Teachers, account uniqueness is based on their first name and last name.

• The teacher's username is generated based on the teacher's first name, last name, ID and school acronym. By default, the username is the same as the password, the teacher can then change the password to a more secure one.

• A teacher must be associated with at least one class/subject. So after initialization, the teacher has no class/subject. But afterward, the teacher can't remove all the classes or subjects he/she is associated with. If this implementation is not required/needed, one could easily call .clear() on the m2m when the request data is empty in the TeacherUpdateView. The admin could clear all teacher's subjects from the admin dashboard.

• Dean can view and update students at any time whether the student is active or not. However, a Teacher can only edit/view a student who is active in a particular year, classe and term.

• The super user account should be created via the custom management command create_super_user and not via the default Django command createsuperuser. This is because the default Django command does not prompt for first name and last name which are required fields in the custom user model. Hence using the default command will result in an error.

• There are four account models: User, Student, Teacher and Dean.

• There are four frontend user roles: student, teacher, dean, admin.

• There are six account types: is_student, is_teacher, is_dean, is_admin, is_staff, is_superuser.

• There are five permission groups: Student, Teacher, Dean, Admin, Staff.

• is_staff and is_superuser are Kralis Management Account Types.

• is_admin is a Kralis Admin Account Type for third party users or school's IT personnel.

• is_student is a Student account type.

• is_teacher is a Teacher account type.

• is_dean is a Dean account type.

• In the frontend, when a student logs in a password pool (not default password), the results he will have access to will be tied to the password pool year, term and classe if they are set, else the student will have access to all results that match the student's current year, term and classe.

CBT

Kralis Computer Based Test System

• A test is made up of multiple questions.

• Tests can be generated from a pool of questions.

• A question can be either one choice or multiple choice.

LMS

Kralis Learning Management System

• A course is made up of multiple modules.

• A module is made up of multiple lessons.

• A lesson is made up of multiple units of topics.

• A unit is content for a specific topic.

• Courses can be issued anonymously or by a teacher but can be viewed by anyone, but only students' progress can be tracked via enrollments.

...more tenets are underway :)