1. Introduction

AutoTimetable (A2Z‑MySchoolApp) is a web application for building and maintaining school timetables and exam schedules. It stores configuration in LDAP, runs optimization in the background, and supports manual editing, substitution, exports, and multiple backup & restore options so you can keep parallel snapshots before major changes.

This manual describes typical workflows. Your school’s LDAP schema, URLs, and enabled options may differ slightly—ask your system administrator if a screen or field is not visible.

2. Access & roles

• Login — Use the credentials provided by your school (usually LDAP). Open the app from index.php.
• Admin — Full access: timetable input, constraints, GA optimization, substitution configuration, exam scheduling, LDAP-backed settings, backup/restore.
• Teacher — Typically sees a personal/weekly view (teacher portal) based on published data.

3. Data & LDAP

Core entities include:

• Classes & sections — Defined per academic year; linked to class teachers where applicable.
• Teachers & staff — Active staff lists, codes, logins; used for assignment and substitution.
• Rooms — Labs, classrooms, grounds; subject and clash rules use these.
• Timetable entry — Often under cn=CurrentTimetable (see config.php / TIMETABLE_DN): attributes such as timetableClasses, alltimetables, constraints, period counts, lunch, games teachers, etc.

The school year may be selected or derived from session—ensure you are working in the correct year before large edits.

Backups and LDAP

Multiple backup & restore lets you capture the current LDAP-backed timetable and constraint state (and optionally GA session files) under several named slots without overwriting earlier saves. Use this before bulk edits, term rollovers, or when testing an alternate solver path—your administrator defines how many slots are retained and whether archives are file-only, LDAP snapshots, or downloadable bundles.

4. Timetable input

Open Timetable input (or equivalent menu from the admin dashboard) to define, per class–section:

• Subjects, period counts, type (theory / lab / skill bands — see below).
• Assigned or empty teacher and room (the optimizer can suggest assignments in some modes).
• Optional daily timing preferences where supported.

Templates & shortcuts

AI or board templates can seed subjects; shortcut maps align template names to your real subject names. Clean, consistent naming reduces mismatch during generation.

Saving

Save your input to LDAP before running optimization so the background process reads the latest timetableClasses (and related) data.

Create a backup first if you are about to change many rows at once—see Multiple backup & restore.

5. Mass lectures

A mass lecture is when the same subject is taught together across multiple sections of the same grade, sharing timing (and usually teacher/room rules).

How to define (timetable input)

• Use subject type theory or lab (not parallel skill types).
• Across sections of the same class (grade), use the same subject name, same type, same teacher, and same room.
• Period counts across those sections should be aligned (the UI may offer tools to equalize mass-lecture periods).

Engine behaviour

The optimizer groups these rows so they are placed in the same slot for all participating sections—like a combined period. If teacher was left empty in auto mode, grouping may follow “same grade + subject + room” rules; if teacher was set, grouping includes that teacher.

6. Parallel skill subjects

Parallel skill rows use types such as skill1 … skill19 (and similar). They model streams where all sections of a grade that offer that skill band should run at the same time (same day/period), while each section can have different subjects, teachers, and rooms inside that slot.

Setup

• Assign the appropriate skillN type to each row that belongs to that band.
• Keep period counts consistent across sections for the same skill band where the product expects parity (check mismatch warnings in the timetable UI).

Engine behaviour

The solver builds atomic groups per (grade, skill type): all participating sections get the same slot for each period index of that stream. Multiple subjects in one section under the same skill type stack in that single slot.

7. Constraints

Open Constraints (e.g. new_constraints.php) to configure hard rules (must not break) and soft weights (penalties). Examples often include daily teacher load, subject repetition, class teacher presence, PE/games rules, room conflicts, and timing preferences.

After changes, save to LDAP. The GA screen usually shows a summary of active hard/soft rules—verify counts before long runs.

8. GA optimization

Open GA / optimization (e.g. ga_timetable.php) after timetable input and constraints are ready.

Parameters

• Generations — How long the search runs (within min/max limits).
• Population / elite — GA-style settings where applicable.
• Solver — Algorithm family (see next section).
• Mode — e.g. Manual (review suggestions before applying) vs Auto (automatic application of certain conflict fixes where implemented).

Default path (SA + CP‑SAT)

The default pipeline often builds a strict seed, persists state, and runs resolve_conflicts.py (OR‑Tools CP‑SAT) as part of conflict reduction—use Resolve Conflicts explicitly when you need another pass without a full GA restart.

Start optimization and monitor progress, charts, and violation logs on the same page.

9. Solvers

The product ships with multiple optimization engines. Pick one from the Solver dropdown before Start or Restart. Your deployment may hide or disable specific options; the table below reflects the full set as implemented in the application code.

10. Pause, resume & stop

Long runs are executed by a background PHP worker (ga_background.php) controlled via session files and UI actions.

• Pause — Requests a graceful stop at a checkpoint; the best timetable found so far is retained. You may sync interim results to LDAP depending on workflow.
• Resume — Continues from saved session state (pending files / control channel). Ensure the same session and that data files still exist on the server.
• Stop — Ends the background job (used before restart or when abandoning a run). A subsequent Restart typically relaunches with updated parameters or after applying manual edits.

If pause or resume times out in the browser, wait and retry—the worker may still be writing checkpoints. Avoid starting duplicate runs for the same session without stopping the previous one.

Pair long runs with multiple backup & restore so you can revert GA session or published grid state if a restart or parameter change produces a worse baseline.

11. After generation

• Review constraint warnings, violation logs, and charts (teacher/room load).
• Use Save to LDAP when you accept the timetable so view_timetable.php and portals see the latest grid.
• Implement suggestions — For manual mode, tick conflict-reduction actions and restart if prompted.
• Download / upload snapshot — Backup or move state between sessions where the UI provides these actions.

Multiple backup & restore

AutoTimetable supports more than one concurrent restore path so operators are not limited to a single “last save”.

• Named slots — Create labels such as “before substitution Friday”, “post skills review”, or “exam week freeze” so teams know which snapshot to trust.
• Scope — Typical options (per deployment) include timetableGenerated / published grid, constraints, timetable input (timetableClasses), and GA / background session files—restore one layer without blindly wiping unrelated LDAP attributes when the UI allows selective restore.
• LDAP vs file vs download — Some slots are written back to the directory; others remain as server-side snapshot files or downloadable archives for DR and audit. Coordinate with IT for retention and off-site copy.
• Restore workflow — Pick a slot, preview impact where offered, then confirm; after restore, re-open view timetable and teacher portal to validate. If Firebase sync is on, confirm whether a re-save should push the restored JSON to the cloud.
• Substitution & portal — Restoring a pre-substitution snapshot may remove substitution overlays in timetableGenerated; communicate with staff before rolling back a live day.

12. Inbuilt teacher substitution

The substitution system is part of AutoTimetable (admin UI, e.g. teacher_substitution.php)—not a separate tool. You select the school day, mark which teachers are absent and in which periods (or use half‑day / full‑day shortcuts), then run Generate substitutions. Use multiple backup & restore before heavy substitution days if you may need to revert the grid quickly.

What the engine does

• Respects LDAP configuration: number of periods, lunch period, games subject/teachers, weekdays, period timings, historical substitution loads (tloads), and teachers who must never be used as substitutes.
• Applies priority-style logic: free periods, class category, avoiding consecutive classes, weekly load, class‑teacher lunch duties, and games‑teacher fallbacks where configured.
• Produces successful and failed substitution rows with reasons, plus updated period‑wise / teacher‑wise / room‑wise views for printing.

Saving to LDAP

When substitutions are applied, the app updates the timetableGenerated attribute on the current timetable LDAP entry. Substitution-specific display data is stored under metadata (e.g. metadata.substitution_teacher_portal.by_day) so the teacher portal can show substitutes and uncovered absences per period without maintaining a second database by hand.

13. Cloud: timetable & substitution (Firebase)

Optional integration pushes the same timetableGenerated JSON (full timetable plus substitution overlays) to Google Firebase Realtime Database so mobile apps, signage, or parent-facing sites can subscribe to updates.

Where data is written

• Path: /timetables (entire document replaced on each successful save—always the latest snapshot).
• Trigger: typically after LDAP timetableGenerated is updated from the substitution workflow (when cloud sync is enabled and configured).

Configuration (LDAP)

Firebase connection details are usually stored on an app-details entry (e.g. under ou=EmpMgmtAppDetails,ou=innovative,o=school,c=in) with fields such as Realtime DB URL (myappurl), database secret, service account JSON, and web app id. Some deployments also expose the same fields in the admin LDAP timetable & substitution & Firebase settings form for easier editing.

Authentication notes

Deployments with App Check on Realtime Database may use service-account OAuth in addition to legacy secret parameters. Coordinate with your administrator for keys, rotation, and Firebase security rules.

After a restore from an older LDAP snapshot, you may need to save or republish so Firebase receives the same JSON the portal shows—confirm behaviour with your admin.

14. Teacher portal

Teachers sign in with their usual credentials and open the teacher portal to see their weekly timetable built from LDAP (timetableGenerated / related data).

Substitution information in the portal

• When admins save substitutions, overlay patches for the selected weekday are merged into timetable metadata.
• The portal can highlight cells where a substitute teacher is covering, where the regular teacher is absent with no cover, and class‑teacher duty notes—so staff see both the base grid and same‑day operational changes.

This keeps timetable and substitution information consistent: one LDAP JSON drives the portal; optional Firebase sync mirrors that JSON for cloud clients.

15. Exam scheduling

Use Exam timetable input to plan exam dates, subjects per class, rooms, and invigilators. The scheduler checks for clashes across classes, rooms, and staff. Data is stored under the exam schedule LDAP entry (see EXAM_SCHEDULE_DN in config).

16. Export & views

• View timetable — Period-wise, teacher-wise, room-wise as implemented.
• Excel / PDF — Use export actions from the admin tools where available.
• Format converter — For interoperability with other tools if installed in your build.
• Backup archives — Where offered, download a multi-component bundle (timetable JSON, constraints, optional session metadata) alongside routine prints; complements in-app restore slots for disaster recovery.

17. Tips & troubleshooting

• Infeasible timetables — Relax soft weights, fix hard contradictions (too many periods vs week length, impossible room sets), or reduce simultaneous mass lectures/skills.
• LDAP errors — Verify LDAP_SERVER, bind DN/password, and attribute size limits for large JSON.
• Python / CP‑SAT — Ensure resolve_conflicts.py dependencies (OR‑Tools) and PHP can spawn subprocesses.
• Performance — Run optimization on the server during off‑peak hours; close duplicate browser tabs polling the same session.
• Backups — Before LDAP bulk edits or solver experiments, create a fresh named backup; verify you can restore on a test window.

← Back to marketing site