Core Concepts & Data Model
Learn the module’s vocabulary once and the rest of this guide reads easily. A handful of objects — learner, guardian link, enrollment, section, class record, grade scheme, report card — and two short state machines explain almost everything the School module does. Two invariants (verified and released) quietly protect the whole system.
The mental model
School is a Student Information System: it moves one learner through a lifecycle and records what happened at each step. Read the pipeline left to right — everything downstream depends on the step before it.
The registrar sets up the academic structure, then admits a learner by driving an application through its checklist to approval — which materialises a roster enrollment. Teachers take attendance and encode grades; the head approves and releases. Only released grades reach report cards and the parent / student portals.
The key objects
These are the nouns you’ll meet on every page. Group them into three domains: identity (who), structure (where they belong), and records (what happened).
Identity — who the learner is
The master record of a student — the identity domain. Holds PII (name, sex, birth date/place, address, contact) plus the LRN. Statuses: active, inactive, graduated, transferred out. Managed on Learners.
Typed identifiers attached to a learner — the LRN (Learner Reference Number) is stored here as an identifier of type lrn. This is the DepEd number that follows a learner across schools.
A parent/guardian directory record — name, relationship, occupation, employer, mobile, email, address. A guardian exists independently and can be linked to one or more learners.
The connection between a guardian and a learner, with access level and primary-contact / pickup / emergency flags. It starts unverified; verifying it (audited) is the authorization spine that later lets a parent portal account see that child.
Structure — where a learner belongs
A school year (with a campus, dates, status) and its grading terms (quarter / trimester / semester). Exactly one year is marked current (is_current) — that flag drives every “current SY” query.
The seeded K-12 backbone — Kinder–G12 grade levels, and the Senior High tracks and strands. This is read-only reference data you build on, not edit. Set up in Academic Structure.
A class group in a grade level (and strand, for SHS) for a school year, with an adviser chosen from active staff, a room, and a capacity (default 40). The unit attendance and grading operate on.
A subject has a subject group, grade level, an is_core flag and units. The subject group is what selects the DepEd Order 8 weight bucket for grading.
Records — what happened
An application is the admissions request (with a document checklist) that moves draft → submitted → approved/rejected. Approving it creates the enrollment — the actual roster placement (status enrolled) of a learner in a school year. Two different things: one is a request, the other is a fact.
A per-learner, per-date, per-session mark — present / absent / late / excused — taken against a section’s current-SY roster. Separate from the employee/biometric HR attendance. See Learner Attendance.
A section + subject + term gradebook. For each learner you encode Written Work (WW), Performance Task (PT) and Quarterly Assessment (QA) scores. It has its own release state (below) and is editable only while draft.
The applicable grading rules — policy (DO8 s.2015 or MATATAG DO10 s.2024), WW/PT/QA weights, transmutation, passing floor — resolved from seeded config by subject group + grade level + school year. Weights are data, not code.
A frozen snapshot that aggregates a learner’s released quarterly grades into per-subject finals and a general average, with a Promoted / Retained remark. See Report Cards.
A support case (guidance/behavioral, with severity and a status flow) — with a confidential safeguarding variant. And a visitor pass issued at the gate. Both live in their own screens with their own lifecycles.
Two state machines you must know
Almost every question about “why can’t I…?” traces back to one of these two flows. Neither lets you skip a step.
1 · Enrollment application
An admissions request moves through these states. Approving is what builds the roster; rejecting ends it.
There are also for_approval and withdrawn states. Approving is
gated: every mandatory requirement on the checklist must be verified or
waived first. The full workflow is on Enrollment &
Admissions.
2 · Grade release governance
A class record’s status controls who can touch it and whether its grades are visible. The order is fixed and enforced.
school_grade_release · teacher submitsschool_grade_approve · head approvesrelease_grades, critical) and locks the grades; only released grades
flow to report cards and the portals. Full detail on the Grading
Engine.
What “verified” and “released” gate
Two words carry most of the module’s safety. Memorise them and most access questions answer themselves.
- Verified (a guardian link)
- A parent portal account can only ever see a child whose guardian link has been
verified. An unverified link grants no portal visibility. Verifying is audited
(
verify_guardian, critical). This is the RA 10173 gate. - Released (a grade)
- A grade is visible on a report card and in the portals only once it is released.
Draft, submitted, and approved grades are not visible to parents or students — only
released ones. Releasing is audited (
release_grades, critical) and locks them.
How School reuses the rest of ERPat
A guiding design choice: School owns the school domain and reuses everything else rather than rebuilding it. Several connections are fail-safe — when the other module is off, School degrades to a notice instead of breaking.
| Capability | Provided by | Notes |
|---|---|---|
| LMS bridge (section → course, roster push) | Learn (module_courses) | Fail-safe Off → the LMS Bridge page shows a notice; School is unaffected. |
| Announcements · Messages · Events | Core module_announcement · module_message · module_event | Communication is a launcher; each tile is gated by whether that module is on. |
| Facility / maintenance tickets | Helpdesk (module_ticket) | Fail-safe Off → Facilities degrades to a notice. |
| Parent / student portal logins | Core customer accounts (allow_customer_signin) | Parents/students are customer users distinguished by their guardian/learner link. |
| Audit trail | Core system_logs | Sensitive actions write audited events; ordinary CRUD uses the base activity log. |
| Notifications | Core notifications | School relies on ERPat’s notification plumbing rather than its own. |
The audit trail
Sensitive actions leave a Data-Privacy (RA 10173) trail. These are the audited actions and their severity — everything else is captured by the base activity log.
| Action | When it fires | Severity |
|---|---|---|
approve_enrollment | An application is approved (roster created) | info |
reject_enrollment | An application is rejected | warning |
verify_guardian | A guardian ↔ learner link is verified | critical |
view_health | A restricted learner health record is viewed | critical |
release_grades | Grades are released / a report card is generated | critical |
view_safeguarding | A confidential safeguarding case is read | critical |
scan_visitor | A visitor pass is checked in at the gate | info |
export | A compliance/masterlist export is downloaded | info |
update_settings | School Settings are saved | info |