Room bookings

Room bookings

The bookings module tracks who has booked which room and when. It’s deliberately not a teaching timetable — it’s the layer above timetabling, for things like:

• Staff meetings
• Parents’ evenings
• Contractor work blocks
• Trust-level training sessions
• Inset days / training days
• One-off events (open evening, awards)

The whole bookings surface sits behind a single permission — estates::agent. There’s no separate per-action booking permission and no “override” right; if you can reach the estates agent rail, you can book and cancel.

Making a booking

A booking captures just a handful of fields:

• Room — picked from the bookable, active rooms.
• Purpose — what you’ll use the room for (required).
• Starts at / ends at — the time slot. The end must be after the start.
• Attendees expected — optional headcount.
• Notes — optional free text.

There are no recurrence options and no separate “booking type” — each booking is a single one-off slot. (Chargeable community-use lets are handled separately in lettings, not as a booking type here.)

How conflicts are handled

A room is single-occupant for a given window. When you submit, the system checks for an existing pending or confirmed booking that overlaps the same room — and if there’s a clash, the booking is rejected with a clear message. The check is race-safe (it locks the room while it checks and writes), so two people can’t both grab the same slot.

It does not consult the curriculum timetable, building closures, or change windows — overlap on the room itself is the only conflict it tests. A booking that’s accepted is created straight away as confirmed.

Cancelling

Cancel a booking and it moves to cancelled — no reason is required, and it’s recorded with who cancelled it and when. There’s no built-in attendee notification; tell attendees yourself, or link the slot to a calendar event (see Integrations) if you want it on their calendars.