System Administrator Playbook

System Administrator Playbook

You bring the School module to life and keep it healthy. This playbook is your operational checklist: enable module_school and run the per-tenant migrations, grant permissions with the segregation of duties the module depends on, configure the portals and the default grading policy, provision and troubleshoot portal logins, and switch on the optional integrations. Everything here is grounded in the live module — reproduce it exactly.

Who you are

You hold school_settings and, typically, the full permission set — you are the person who turns the module on for a tenant and decides who can do what inside it. You do not have to be a teacher or registrar; you are the operator. Your two most important jobs are making the module reachable on every tenant and separating the grade-release duties so no one can publish their own grades.

The permissions you work with

Permissions are granted in the core Roles editor. The base permit is school; each of the 14 pages has its own “Enabled” toggle, and sensitive actions add restricted or segregated permits. You will spend most of your time on the handful below.

The complete permission list — page enablers, CRUD children, and restricted permits — is in the Screen, Route & Data Reference, and the suggested per-role presets are in the Roles & Access Map.

SOP 1 — Enable the module and migrate every tenant

The school_* tables are created per tenant. Turning the module on in Settings does not create the tables — you must run the module migrations on each tenant database, and validate them there, before staff use the pages.

1. Turn the module on

   Go to Settings → Manage Modules and enable School. This flips the module_school setting for the current tenant.

2. Run the module migrations

   From the project root, run the migration command so the school_* tables (tracked in migrations_school) are created on this tenant:

   php erpat migrate:modules

3. Repeat and validate on every tenant

   Because school tables are per-tenant, run and confirm the migrations on each tenant database where School will be used. A tenant that has module_school on but no migrations run will show empty pages or errors.

4. Confirm the sidebar

   Sign in as a user with the school permit and confirm the single School menu group (graduation-cap icon) appears with its pages.

SOP 2 — Grant permissions and enforce segregation of duties

Grant the base school permit plus the page enablers each role needs, then be deliberate about the two grade permits and the restricted domains.

1. Give each role its pages

   In the Roles editor, enable the page permits the role needs — for example the registrar gets school_enrollment, school_learners, school_guardians, school_academics and their create/update children; a teacher gets school_attendance + school_attendance_update and school_grades + school_grades_update.

2. Split the grade duties across two people

   Grant school_grade_release to the encoder/teacher and school_grade_approve to the school head — never to the same person. The encoder submits; the head approves and releases. The system prevents a person from approving their own grades.

3. Lock down the sensitive domains

   Grant school_health (clinic/nurse) and school_child_protection (guidance) only to the specific people who need them. Every view of those records is written to the audit trail.

SOP 3 — Configure School Settings

The School Settings page (school/settings) carries a small set of toggles and the default grading policy. Saving is audited (update_settings).

SOP 4 — Turn on customer sign-in and reach the portals

The parent and student portals reuse the existing customer sign-in, so they also depend on the core allow_customer_signin setting being enabled. With that on and the relevant portal toggle enabled, the portals are reachable.

1. Enable customer sign-in

   Confirm the core allow_customer_signin setting is on. Without it, a provisioned parent or student account cannot log in even though the portal is enabled.

2. Point people to the portal

   Once customer sign-in and the matching portal toggle are on, a provisioned parent signs in and lands on 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). Each portal controller enforces its own access checks — a parent only ever sees their verified children and only released grades; a student only their own record. If the portal setting is off, the route returns “not found”.

SOP 5 — Provision and troubleshoot portal logins

A portal account is created from a person’s profile, not signed up by them. Parent logins are provisioned from the guardian record (“Provision portal login”, needs school_guardians_update); student logins from the learner record (needs school_learners_update).

1. Make sure the profile has an email

   Provisioning creates a customer user from the guardian’s or learner’s email address. No email → provisioning is refused.

2. Provision the login

   On the profile, choose Provision portal login. The system creates a customer account with a temporary password.

3. Have the person set their own password

   Tell the parent/student to open the sign-in page and use forgot password to set their own password. They never need to know the temporary one.

4. For parents — verify the guardian link first

   A parent will only see a child once that guardian ↔ learner link is verified. Verification is a separate registrar action on the guardian record; provisioning the login alone does not grant visibility.

Point parents and students at their own friendly guides — the Parent Portal Playbook and the Student Portal Playbook — for signing in and reading their data.

SOP 6 — Enable the optional integrations

School deliberately reuses the rest of ERPat rather than rebuilding it. Each integration is optional and fail-safe — when the partner module is off, the School screen shows a notice and its actions no-op; grading and the portals are unaffected.

Grade schemes are configuration, not code

The grade engine (School_grade_engine) is pure and config-driven — it holds no database and no hardcoded weights. The applicable scheme (policy + WW/PT/QA weights + transmutation rule + passing floor) is resolved from seeded configuration by subject group, grade level, and school year. Two things to keep straight:

The default policy setting

school_default_grading_policy chooses DepEd Order 8, s.2015 or MATATAG DO10, s.2024 as the default the engine resolves against.

The per-grade scheme

The actual weights come from the resolved scheme for that grade level and subject group. If no scheme exists for a grade/subject-group/year, saving a class record errors with “no scheme” — that is a configuration gap, not a bug. Never hardcode weights.

The full policy comparison, weight buckets, and transmutation behavior are in the Grading Engine page.

Keeping the module healthy across tenants

Treat every tenant as its own school. When you make a change, ask whether it needs to reach each tenant DB.

Where to next