What a guardian can and cannot be told

The parent portal's promise is that a guardian stops having to phone the site for every small question. That promise crosses four other parts of PTRS, and each one contributes a different answer. This page holds all of them in one place.

Each row below is marked live, meaning the fact is real and correct; empty, meaning nothing behind it can ever hold data; or partial, meaning some of it is real and some of it cannot be.

Attendance: mostly live

Fact	State	Why
Did my child arrive today?	Live	Read straight from today's real arrival record, created by staff at check-in
Which site are they at?	Live	Resolved from that same record
Have they been signed out?	Partial	A staff check-in drawer sets this correctly. A kiosk check-out never does, because the kiosk sends a placeholder value where a guardian's own id belongs, so PTRS refuses the request before it can set anything
Their arrival history	Live	Read directly from real check-in records, not from the summary table that leaves several other parts of PTRS empty
Hours this week	Empty in practice	Only counted from records that have a check-out. With kiosk check-outs broken, this reads zero for any child signed out at a kiosk
Days present this week	Live	Counted from real arrival dates

A note on the week boundary: the weekly summary works out its own week using universal time, not Delaware time. Between roughly 7 in the evening and midnight Eastern on a Sunday, the "week" has already rolled over to the next one.

Their programme: live but oddly shaped

Each active enrolment's programme is read correctly, and the shape of the reply does not match what its own field names promise. The field meant to hold a day of the week actually holds a free-text description such as "Monday and Wednesday, 3 to 5". The fields meant to hold start and end times actually hold the programme's own start and end dates, not times of day at all.

No screen shows any of this today. The one component built for it expects a day of the week in a different shape than what it would actually receive, and would show "No programs scheduled" over enrolments that are genuinely active.

Health and safety: one live, one permanently empty, two live and unreachable

Fact	State	Why
Medicines held on site for my child	Live	Read from real, active records kept by Health & Safety
Was the medicine given, and when?	Empty	Nothing in PTRS can write this record at all, on the staff side or here. The log a guardian would be shown can only ever be blank
My child's emergency action plan	Live	Read from real records kept by Health & Safety
Illness records and return dates	Live	Including the date a child becomes eligible to return, the figure a guardian actually needs

The last three are live, and none of them has anything on the guardian's own device that could ever ask for them, so no screen can show them.

The medication log is the sharpest version of the module's problem

A guardian looking at an empty medication log for a child who has an inhaler on site cannot tell "it was not needed today" apart from "PTRS cannot record that it was given". Only the second is true, and it is true every single day.

Incidents: live, and it would show more than it should

A child's own incident involvement can be read correctly, and the read itself describes its own output as guardian-safe fields only. Looking closely at what it actually returns, three things do not hold up.

It filters on no status at all, so an incident that is still a draft, typed but never submitted, reviewed or approved, would be shown to the guardian exactly like a finished one. It returns the reporter's raw, unedited narrative rather than the cleaned-up version PTRS also keeps, and a raw narrative can name other children. And the type and severity shown are whatever PTRS happened to store, which is not necessarily what the reporter actually chose, since nothing checks that those fields were ever filled in correctly in the first place.

Nothing on any guardian's device today ever asks for this read, so none of it reaches anyone yet. It is the one place in this module where connecting the missing screen would make things worse, not better, until these three things are fixed first.

Staff notes: live, and it does not respect the confidentiality flag

The weekly summary returns every staff note written about a child during that week, word for word.

Staff notes can be marked confidential, and this read does not check that flag at all. It also does not check what kind of note it is, so a behavioural note, or a note about a conversation with the other guardian, passes straight through unchanged. The only thing it checks is whether the note was deleted.

Like the incidents read above, this is safe today only because nothing asks for it. It is the second of two places where the safe outcome is an accident of an unfinished feature, not a decision anyone made.

Messages: one direction, and it fails

Fact	State
Can a guardian send a message to staff?	No. The message box sends a placeholder value where a real staff id belongs, and PTRS refuses the request before it is even read
Can staff send a message to a guardian?	No. The only thing that ever writes a message always marks it as sent by the guardian. There is no staff-facing screen for this anywhere in PTRS
Is a message ever read by anyone?	No. Nothing on the staff side reads a guardian's messages at all
Does a message ever get marked read?	No. Nothing sets that field, which is why the dashboard's unread count is permanently zero
Is a message ever translated?	No. Nothing performs that translation, even though PTRS tracks how long it would take

Notifications: nothing, by every channel

This is the question that matters most in this module, so it was tested against four separate possibilities rather than assumed.

Possibility	Result
A parent message notifies the staff member	No such path exists
An emergency alert reaches a guardian	No alert can ever be created
A form reminder is sent	No form can ever be created, and no reminder check exists either
A check-in notifies the guardian	Nothing listens for a check-in to act on it

No path in this module has ever sent a notification of any kind, anywhere in the product, across all twenty things this module can do.

Three deeper reasons sit behind that. PTRS has never actually created a notification record by any path at all, anywhere. Email reports success without actually sending anything, because no outgoing mail server is configured in any installed copy of PTRS. And two of the four contact channels, text message and phone call, have no delivery method built for them at all, so choosing either one on the settings screen chooses a channel that plainly does not exist. A saved phone token for push alerts is collected correctly and has nowhere to be delivered to either.

What this adds up to

A guardian using PTRS today can learn exactly one new thing they could not learn before: whether their child arrived at the club today, and at which site.

That single fact is real, correctly guarded, and accurate.

Everything else on the portal's promise, a message, an alert, a signed form, a medication record, a weekly summary, is either unreachable from any screen or reads from something that can never hold data. The two places where the portal would show a guardian more than it should, incidents and confidential staff notes, are safe today only because nothing asks for them yet.