School calendar & events.

At the centre of this module is one table — school_calendar_events — and one promise: every date the school cares about lives there once, and every screen reads from it. A holiday, a closure, a meeting, an exam, an assembly, a parent day, a sports day, a general event — all of them are rows of the same shape, differing only by type.

But the calendar is more than what an admin types in. It is an aggregator. The terms and holidays the academic structure already holds flow in automatically. Exams, field trips, parent-teacher conferences, live classes, holiday-class sessions — each surfaces on the calendar from its own module, so the family looking at "what is coming up" sees the whole school, not just the events someone remembered to re-enter.

Every date the school cares about, in one place, in every reader's language, on every device.

Follow one term and the rest of the book is detail.

Before term. The registrar sets the academic year and its three terms in the academic structure, and enters the half-term break as a term holiday. Without anyone re-typing it, that holiday appears on the school calendar as an all-day event that cancels the timetable — a database trigger mirrored it across.

Week one. The head opens /dashboard/events and creates the term's fixtures: a parent evening (RSVP on, capacity 200), a sports day (all-day, cancels lessons), a staff meeting. Each starts as a draft; one click publishes it, and notify parents fans a notification out to every family in their own language.

Mid-term. A parent opens /portal/calendar on her phone. She sees the parent evening, her daughter's exam dates, the consented field trip, and the fee due date — all colour-coded by source. She taps the parent evening, RSVPs going for two, and the seat count ticks up. The event was already near full; a later canceller frees a seat and the next person on the waitlist is promoted automatically and notified.

All term. A teacher who pasted his YESS calendar link into Google Calendar weeks ago never opens the app at all — his classes, his invigilation slots, and the school events simply appear on the phone he already checks.

Events are created and managed at /dashboard/events — a card grid with a KPI strip, type and status filters, and create/edit/delete/publish. Every event carries a handful of decisions:

At the row level every in-school user can read and write calendar events — the finer control of who may create or publish lives in the permissions above, checked by the screen. Renaming or moving a published event updates it everywhere it appears at once.

The calendar is not where you define the academic year — that lives in the academic structure, with the terms and their holidays. But you should never have to enter a holiday twice, so YESS bridges the two automatically.

Holidays sync by trigger. When a term holiday is created, edited, or removed, a database trigger mirrors it into school_calendar_events as a published, all-day, timetable-cancelling holiday — matched back to its source row so an edit updates the calendar copy and a delete removes it. A one-time backfill brought existing holidays across when the bridge was built.

Term and year boundaries appear as markers. The school-wide calendar at /dashboard/calendar projects read-only markers for "term begins / ends" and "academic year begins / ends" straight from the structure. These are synthetic — you cannot edit or delete them from the calendar, because the calendar is reading them, not owning them. Change a term's dates in the academic structure and the markers move with it.

The staff calendar at /dashboard/calendar is the fullest view — an agenda hero over a month-and-week grid, with source filter chips. It merges eight streams into one surface: published school events, the term and year markers, exam sessions, holiday-class windows, field trips, parent-teacher conferences, live classes, and the holidays synced from the structure. Each source is colour-coded so a glance tells you whether a block is an exam, a trip, or a meeting.

Because the calendar is projecting from live modules, it is always current. Schedule an exam in the examinations module and it appears here; confirm a field trip and it lands on the calendar; book a parent-teacher conference and it shows for both parties. Nothing here is a stale copy waiting for a refresh.

An event can ask for a reply. When an event is marked RSVP-required, the portal renders a response block on the event's page at /portal/events/[id] with three buttons — going, interested, can't make it — and a party-size selector. Responses are written through a database function into the school_event_rsvps table, one row per person per event, with a capacity bar showing seats taken against the limit.

The waitlist runs itself. If an event is full and a waitlist is enabled, a new going reply is parked as waitlisted with a queue position rather than rejected. When a confirmed attendee later cancels, a trigger fires a promotion routine: the next person on the waitlist is moved into the vacated seat, notified with a deep link to the event, and the queue is renumbered. No organiser has to chase the list.

The same events reach each audience as a feed shaped for them. A parent or student opens /portal/calendar (or the simpler "what's coming up" list at /portal/events) and sees a personal merge: published school events aimed at them, their own exam schedule, consented field trips, parent-teacher conferences, holiday-class sessions, assignment due dates, and fee due dates — each colour-coded by where it came from, windowed to the months around today.

A teacher opens /teacher/calendar and gets their own merge — school events for staff, exam sessions, their live classes, and their assignment deadlines. The role-group audience you set on an event is honoured here: a staff-only event does not clutter a parent's feed.

And when an event is published with notify parents on, the calendar does not wait for anyone to open a screen — it dispatches a notification to every family in their preferred language, so the date arrives even before they look.

The most-loved feature in this module is the one a school never has to explain twice: a personal subscription link that drops the YESS calendar straight into Google Calendar, Outlook, or Apple Calendar. Each user has a private feed at /api/cal/[token] — a standards-compliant iCalendar feed they paste once and forget.

The feed is built per person and is richer than any single screen. For a student it carries school events and their exams; for a parent, the same for every linked child, prefixed with the child's name; for a teacher, their weekly timetable as a proper recurring series (with the right days skipped when a substitution covers them), their invigilation slots, field trips they lead or accompany, holiday-class sessions, parent-teacher conferences, and university-style course sessions. It looks sixty days back and a year ahead, and refreshes itself every few minutes.

The event record, draft-and-publish, the term-and-holiday sync, the aggregated calendar, RSVP with a waitlist, the personal feeds, the notify-parents fan-out, and the iCalendar subscription are all live. The honest gaps below are still being finished.

The calendar is a junction — it projects dates from across the platform and pushes them out to every reader.