Administration, Settings & Portals
This is the administrator's control room for the School module: how you turn it on and create its tables, how the School Settings page and its toggles behave, how permissions are granted and — critically — separated, how parent and student portal logins are provisioned, and how School quietly reuses the rest of ERPat through fail-safe integrations. Everything here is grounded in the live module; keep it beside the System Administrator Playbook and the Screen, Route & Data Reference.
school_default_grading_policy setting only chooses the default policy; the
actual weights come from seeded schemes. See the Grading Engine.
Enable the module & create its tables
School is a self-contained ERPat module (slug school, URL prefix
/school, sidebar group School under Academics). Enabling it is two
steps, and the second one is per tenant — the school_* tables are created
in each tenant's own database, so a school that exists on one tenant does not automatically
exist on another.
-
Turn on
module_schoolGo to Settings → Manage Modules and enable School. This flips the
module_schoolsetting to1, which reveals the sidebar group, injects the School permissions into the Roles editor, and un-gates the portals. -
Run the module migrations on this tenant
From the project root, run the module migration command so the 42
school_*tables (tracked inmigrations_school) exist on the current database.php erpat migrate:modules -
Repeat / validate on every tenant that needs School
Because the tables are per-tenant, run and validate the migration on each tenant database where the school will operate. A core settings-seed migration ships
module_schooland the portal/feature toggles so their defaults resolve cleanly.
php erpat migrate:modules hasn't been run against that tenant's
database. Validate the migration per tenant before enabling.
School Settings
The School Settings page (school/settings, permission
school_settings) is a short, deliberate list of toggles plus the default grading
policy. It does not hold operational data — no school year, no rosters. Saving is
audited (the update_settings action, see
Data Privacy & Safeguarding).
| Setting key | Values | What it controls | Set where |
|---|---|---|---|
module_school | 1 / 0 | Master enable for the whole module — sidebar, permissions, routes, portals. | Settings → Manage Modules |
school_parent_portal_enabled | 1 / 0 | Turns the parent portal (school/parent) on or off independently. When off, the portal returns a 404. | School Settings |
school_student_portal_enabled | 1 / 0 | Turns the student portal (school/student) on or off independently. When off, the portal returns a 404. | School Settings |
school_visitor_pass_enabled | 1 / 0 | Shows or hides the Visitor Pass page in the staff sidebar (the menu child is gated by this setting). | School Settings |
school_default_grading_policy | do8_2015 (default) / matatag_do10_2024 | The default grading policy used when a scheme is resolved. It selects DepEd Order 8 s.2015 or MATATAG DO10 s.2024 — but the actual weights come from the seeded schemes, not this key alone. | School Settings |
allow_customer_signin core | 1 / 0 | ERPat's core toggle that lets customer accounts sign in. Both portals reuse the customer sign-in, so this must be on for parents/students to log in. | Core ERPat settings |
allow_customer_signin and the matching
portal toggle are on, a provisioned parent signs in and reaches the parent portal at
school/parent and a student at school/student (the
school/portal dispatcher also routes a signed-in customer to the right one).
Access is enforced by each portal controller — a parent only ever sees their
verified children and only released grades; a student only their own record.
If a portal’s setting is off, its route returns “not found”.
Permissions & segregation of duties
The School module owns all of its permission keys — nothing is added to ERPat's core
Roles logic. While module_school is on, these keys appear in the Roles
editor, grouped by category. Grant them per role. The base key is school; every
page has an Enabled toggle, and sensitive work has its own separated key.
Page enablers (one per screen)
| Permission key | Unlocks |
|---|---|
school | Base module access + the Dashboard. Required before any other School permit does anything. |
school_enrollment | Enrollment & Admissions page. |
school_learners | Learners master index. |
school_guardians | Parents & Guardians directory and links. |
school_personnel | Personnel & Teachers registry. |
school_academics | Academic Structure (years, terms, sections, subjects, rooms). |
school_lms | LMS Bridge (also needs the Learn module). |
school_attendance | Learner Attendance register & records. |
school_grades | Grades & Report Cards page. |
school_communication | Communication launcher. |
school_support | Student Support (guidance) cases. |
school_visitors | Visitor Pass page (also needs the visitor-pass setting). |
school_facilities | Facilities & Rooms summary and tickets. |
school_reports | Reports & Compliance page. |
school_settings | School Settings page. |
CRUD children (create / edit / delete)
| Area | Create | Edit | Delete |
|---|---|---|---|
| Enrollment | school_enrollment_create | school_enrollment_update (also approve/reject) | school_enrollment_delete |
| Learners | school_learners_create | school_learners_update | school_learners_delete |
| Guardians | school_guardians_create | school_guardians_update (also verify link, provision portal) | school_guardians_delete |
| Personnel | school_personnel_create | school_personnel_update | school_personnel_delete |
| Academics | school_academics_create | school_academics_update | school_academics_delete |
| Attendance | — | school_attendance_update (record/edit) | — |
| Grades | — | school_grades_update (encode/edit) | — |
| Support | school_support_create | school_support_update | — |
| Visitors | school_visitors_create (issue/scan) | — | — |
| Facilities (Rooms) | school_facilities_create | school_facilities_update | school_facilities_delete |
Segregation-of-duties & restricted-domain keys
| Permission key | Grants | Note |
|---|---|---|
school_grade_release | Submit Grades for Release — the encoder/teacher submits a class record. | SoD Give to teachers. |
school_grade_approve | Approve / Publish Grades & Cards — approve, release, and generate report cards. | SoD Give to the head — a different person than the encoder. |
school_health | Learner Health / Medical (view) — restricted, audited on view. | restricted Give to clinic/nurse. |
school_child_protection (+ _create / _update) | Child Protection / Safeguarding — the confidential case surface, segregated and audited on every read. | restricted Give only to safeguarding officers. |
school_export | Export / Compliance Downloads — the masterlist CSV and compliance exports. | Audited on use. |
school_grade_release and
school_grade_approve to the same person — the encoder must never be able to
approve and publish their own grades. Likewise, keep the restricted school_health
and school_child_protection permits to the smallest possible set of staff; both
log every read. Full rationale in Data Privacy & Safeguarding.
Portals & customer accounts
Parents and students do not get staff logins. Both portals reuse ERPat's existing
customer account type: a parent is a customer whose account is linked (through the
verified guardian link) to one or more children; a student is a customer whose account is
linked to their own learner record. A small dispatcher at school/portal resolves
which one the signed-in customer is — strictly from the session user id — and forwards to
school/parent or school/student. A signed-in customer with no
School role sees a friendly "no role" page, never an error.
What a portal needs to work
- Module + portal toggle
module_school = 1and the matchingschool_parent_portal_enabled/school_student_portal_enabledset to1. If either is off, the portal returns a 404 (existence is hidden).- Customer sign-in
- The core
allow_customer_signinmust be enabled, because the portals reuse the customer sign-in screen. - A provisioned login
- The parent/student needs a customer account created from their guardian/learner profile (below).
- For parents: a verified link
- A parent only sees a child whose guardian link has been verified. An unverified link shows nothing — by design.
Provision a portal login
Provisioning lives on the guardian or learner profile (Provision portal login), and
needs school_guardians_update / school_learners_update. It creates
a customer account with a temporary password shown once; the person then uses
forgot-password to set their own.
Make sure the person has an email
Provisioning requires a valid email on the guardian/learner record — it becomes the sign-in username. Without a valid email, provisioning is refused ("needs email").
Click "Provision portal login"
On the profile, choose to provision. The system creates an active customer user and shows a one-time temporary password.
Hand over the temporary password
Give the person the temporary password (or ask them to use forgot-password immediately). They set their own password on first use.
Confirm the link (parents) or record (students)
For a parent, ensure at least one child link is verified so the portal has something to show. For a student, the account resolves the learner from their record automatically.
Optional module integrations
School deliberately reuses the rest of ERPat instead of rebuilding it. Every integration is optional and fail-safe: when the partner module is off, the School page degrades to a notice (or hides a launcher tile) — never a fatal error. Grading, portals, and the core workflows are unaffected.
| Integration | Enabled by | What School uses it for | If disabled |
|---|---|---|---|
| Learn (LMS) | module_courses | LMS Bridge — link a section to a Learn course and push the roster as enrollments. | The LMS Bridge page shows a notice; every action no-ops. |
| Helpdesk | module_ticket | Facilities — facility / maintenance tickets. | Facilities still shows the room summary; ticketing degrades gracefully. |
| Announcements | module_announcement | Communication launcher tile — school-wide / section announcements. | The tile is hidden. |
| Messages | module_message | Communication launcher tile — parent–teacher / student–teacher messages. | The tile is hidden. |
| Events | module_event | Communication launcher tile — the school calendar. | The tile is hidden. |
The Communication page is purely a launcher — it never duplicates announcements, messaging, or the calendar; it links into the core modules. See LMS Bridge & Communication for the operational detail.
Grade schemes are configuration, not code
A common admin question: "where do I change the WW/PT/QA weights?" You don't hardcode them.
The school_default_grading_policy setting only picks the default policy
(DO8 s.2015 or MATATAG DO10 s.2024). The actual weights, transmutation rule, and passing
floor are resolved by the grade engine from seeded schemes — by subject group,
grade level, and school year. That is why a Science class and a Filipino class under DO8 use
different weights automatically.
Administrator setup checklist
- Module on:
module_school = 1(Manage Modules). - Tables created:
php erpat migrate:modulesrun on every tenant that uses School. - Roles set: page enablers granted per role;
school_grade_releaseandschool_grade_approveheld by different people. - Restricted permits limited:
school_healthandschool_child_protectiongiven only to guidance/clinic staff. - Settings reviewed: portal toggles, visitor-pass toggle, and default grading policy set intentionally.
- Portals ready:
allow_customer_signinon; parent/student toggles on; logins provisioned; parent links verified. - Current SY set: one School Year marked current in Academic Structure.
- Integrations decided: Learn / Helpdesk / Announcements / Messages / Events enabled as needed.