Work the schedule and calendar screens
A program's schedule cannot be set, and no session, exception or room booking can be created, from anywhere in PTRS. Three separate failures each block it on their own, so fixing any one of them changes nothing.
This page is here so you can tell which control has failed and stop trying. It is not a route to a working schedule, because there is not one today.
The three failures, in the order you would hit them
1. Save Recurrence sends nothing
Edit Recurrence on the Schedule tab opens a real editor: pick a frequency, an interval, days of the week, a start and end time, an effective date range, and it prints back a plain sentence describing what you built, something like "Repeats every 2 weeks on Mon, Wed from 15:00 to 17:00 until 1 June 2026".
Press Save and nothing happens. No request goes out, no message appears, no error is shown, and the panel stays open.
The editor is a genuine, working piece of code with nothing wired up to give it what it needs, so it behaves as if there is no schedule to save no matter what you build in it.
So a program's recurrence pattern, its start and end times, its days of the week, its effective dates and its default room all have nowhere to be saved. Every program's schedule stays exactly as it was created, named Default, with none of those settings filled in.
2. Generate Sessions asks for an identifier it can never have
Generate Sessions opens a dialog for a start and end date. Fill both in, press Generate, and the dialog stays open.
The request needs to know which schedule to generate sessions from, and the screen tries to work that out from the first session already on the list, the very records this button exists to create. With no sessions yet, that value is blank, and the request cannot go anywhere sensible. The result is a plain, unhelpful error, indistinguishable from a missing program.
Even with a working schedule identifier, generating a session also needs a saved recurrence pattern and both times, which failure 1 already rules out.
3. Add Exception fails the same way
Add Exception takes a date, a type (Cancelled, Modified, Added) and a reason, and runs into the identical blank-identifier problem as Generate Sessions.
What the rest of the Schedule tab does
The three tiles, Scheduled, Completed and Cancelled, count the sessions currently on the list. They read 0, 0, 0 on every program.
The four filter tabs, All, Scheduled, Completed and Cancelled, work correctly and filter what little there is to filter.
The session list reads "No session occurrences found. Generate sessions from a recurring schedule to get started." on every program, permanently.
The Complete and Cancel buttons on a session row are correctly built and only ever render on a session row, so they never actually appear anywhere. If a session existed, Complete would mark it completed, and Cancel would mark it cancelled with a fixed reason, "Cancelled by staff", typed in whether or not that was the actual reason.
The Program Calendar
The Program Calendar shows a month grid of room bookings, with a warning triangle on any day carrying a schedule conflict, and a sidebar listing the selected day's bookings and conflicts.
It reads two things, and both come back empty on every site:
- Room bookings. Booking a room is built correctly: it checks the room exists and refuses an overlapping booking in the same room. Nothing in the interface ever calls it, so the grid is empty on every month.
- Schedule conflicts. The conflict checker compares bookings against other bookings, and sessions against bookings. With both tables empty, it always reports nothing, so no warning triangle ever appears.
The legend lists three booking states. Only one, Tentative, can ever actually exist: nothing in PTRS ever sets a booking to Confirmed or Cancelled, and there is no control anywhere to update or remove a booking.
It is linked from nowhere. No menu, tab or link anywhere in PTRS points at the Program Calendar. The only way to reach it is to type its address directly.
It is the one Programs screen a regional director can fully load. Its two checks are among the few in this module that carry no narrower requirement beyond the group setting, and that setting does admit the role. Every other Programs screen depends on the program list or a program's own detail, which both require the narrower setting and refuse it.
The recurrence rule would not be honoured anyway
Worth knowing before anyone fixes the three failures above, because it changes what "fixed" would actually mean.
The schedule editor builds a genuine recurrence rule in the technical format calendar software expects, and the part of PTRS that would turn it into real sessions never reads that rule at all. It checks only that the field is not blank, then walks the date range one day at a time and keeps whichever days of the week were separately selected.
| What the editor lets you set | What actually happens |
|---|---|
| The days of the week you tick | Honoured, through a separate setting, not through the rule itself |
| A weekly repeat | Honoured by accident, because that is the only pattern the day-by-day walk produces |
| A daily or monthly repeat | Ignored. Sessions still land only on the ticked weekdays |
| An every-other-week repeat | Ignored. Sessions are generated every week regardless |
| An end date or a fixed number of repeats set on the rule itself | Ignored. Only the date range you type into Generate Sessions, narrowed by the schedule's own effective dates, is honoured |
| No day of the week ticked at all | Falls back to Monday through Friday |
So the plain-language sentence the editor prints back, "Repeats every 2 weeks…", describes behaviour that nothing downstream actually carries out.
What does work, for an integration
The pieces on PTRS's own side are sound and can be driven directly by someone building against it, even though no screen exposes them today. If that is you, this is the working sequence:
- Save the schedule's recurrence pattern, start and end time, and days of the week. Only the days of the week are what generation actually reads.
- Record holidays and closures before generating sessions, because generation skips a date marked Cancelled and applies a Modified date's times.
- Generate sessions for a start and end date. This step can be repeated safely over an overlapping range: PTRS checks what already exists and adds nothing twice.
- Book a room for each slot you want the calendar and its conflict checker to have anything to work with.
Two behaviours worth designing around:
- Every generated session inherits its schedule's own default room. Two programs sharing a default room will generate overlapping sessions, and the conflict checker will not catch it, because it never compares sessions with other sessions, only sessions with bookings.
- Marking a date Cancelled after sessions already exist cancels the matching session too, on top of blocking future generation on that date. A Modified or Added date does not touch a session that already exists.
Where to go next
- Who can do what with a program's setup, schedule and enrolment
- Program and enrolment fields, the field rules for someone integrating directly
- Programs troubleshooting
Checked against PTRS on 7 September 2026.