-
Notifications
You must be signed in to change notification settings - Fork 109
Technical overview
The application largely relies on Backpack for Laravel. The user management is done by Backpack. We rely on roles and permissions to differentiate students and teachers, but all types of users are stored as User models.
A period is, for instance, a trimester. It belongs to a Year model: this allows us to compute reports with totals for the whole year.
This model is not yet fully used. We need it to make the difference between internal courses (ID=1) and external courses (ID=2).
A campus has many Room models.
The course core information is defined through its relations with other models: a course belongs to a campus, a level, a teacher (User), a room, a rhythm (= the course category) and a period.
A course also has relations to CourseTime an Event models. A CourseTime defines the day and hours of every class, which repeat through the course date span. Event models represent each class session.
A course has many Enrollment models.
A course may have a parent Course: this is used when a single course has several modules within the same period. For instance a course that covers levels 1 and 2 may be divided into two child courses (one for each level). In this case, we create models for each child courses (DB field parent_course_id), as well as a model for the parent course. Creating an enrollment in the parent course automatically creates enrollments in child courses.
Finally, a course may have EvaluationType models attached to it (grades-based evaluation, skills-based evaluation, etc).
An Event represents a session of class. It has precise start/end dates. It belongs to a Course and to a CourseTime. When a CourseTime model is modified, we need to update all related Event models
A Grade model represents an individual grade obtained by a student. It belongs to a course and to a GradeType
For instance: oral interaction, grammar, final exam, etc. A GradeType will be attached to a course. In this case, it will appear in the grades list, for the teacher to enter the grade of each student.
In the situation of skill-based evaluation, we attach Skill models to the course. A Skill belongsTo a SkillType (very much like Grade <-> GradeType) and a Level.
When assessing the students' performance, a SkillEvaluation model is created, which links the Skill to the User, and to a SkillScale model (for instance: "adquired", etc.)
The Result model stores the final decision for an enrollment. It links a ResultType (passed, failed, etc) to an enrollment. A Comment model can be attached to the Result model.
An Attendance model links a User and an Event. For every class, the teacher will create an Attendance record for each student enrolled in the course.
An Attendance model belongsTo an AttendanceType model (present, absent, late, etc). When an Attendance model is created with a specific AttendanceType, we will need to send an email to the student and/or their parents. Through model events, we watch for such a record, and trigger the appropriate actions when it is created.
We use a unique table to store all types of comments. Polymorphic relations allow us to link each Comment model to another model - mainly Enrollment, Grade, Result, PreInvoice.
A fee will be, for instance, an administrative fee that will be charged to the users in addition to an enrollment.
After the enrollment has been paid, a PreInvoice is generated. This model is linked to the Enrollment model via a n-n relationship: a single enrollment can be paid with several pre-invoices, and (more frequently) a single invoice may cover several enrollments.
The pre-invoice represents the data that will be sent to the accounting software. The invoice contact, date, final price, etc are kept in the DB, along with the (real) invoice number that has been generated by the accounting software.
The PreInvoice hasMany PreInvoiceDetail models, which represent all the products that have been purchased with this invoice. -- another solution might have been to serialize all the products and store them in the preInvoice model. Which is better?
Represents the teacher holidays or other leaves (LeaveType models)
The application counts the number of hours taught by each teacher, using the dates provided on the Event models. We amy also want to count hours without a specific date/time: we can store these hours as RemoteEvent models.
The User model represent students, teachers and admins alike. Roles and permissions allow us to filter users and to redirect them to the appropriate routes in the app.
Users are created and are able to log in according to their role:
- administrators have full access to every feature
- secretaries have access to enrollments management, student information and so on
- teachers have access to features related to their courses and students
- students
A student may have additional contacts attached to their profile. Since we don't need these contacts to be full-fledged users, we store them in as UserData models. A UserData model also has a UserDataRelationship, which is used to indicate whether the nature of the relationship between the student and the additional contact (e.g. family, work, etc)
A user may have several phone numbers. The same model is also used for additional contacts, which is the reason why we use a polymorphic relation in this model.