Who can do what in the parent portal
20 is the whole count of things PTRS can do in this module. Every one of them sits on one group, with no second group and nothing registered anywhere else that reaches these saves and reads.
Who is admitted
Every one of the 20 actions was checked directly, and not one narrows or widens the group's own setting. This is the flattest access pattern in PTRS, flatter even than Analytics, and this module is the only one in the whole product a super admin's account cannot use through the server, because it names one role and nothing else.
The two joins where the pattern stops being flat
PTRS itself is wider than the server. It lets a guardian, an organisation administrator and a super admin all open the portal's screens, and the server accepts a guardian account alone. The guardian role is the only role in PTRS matched exactly by a screen-side setting of the same name, and no parent-portal screen actually checks that setting, so it never runs. An organisation administrator opening a parent web address gets the full shell; signing in only resolves a guardian id for a guardian account, so every request from that administrator stays switched off and the screen looks empty rather than forbidden.
A guardian is not stopped from four staff screens. PTRS lists fifteen staff areas to redirect a guardian-only account away from, and it leaves out four that exist. A guardian reaching one of those four gets the full staff layout and a refusal from every request behind it.
The check that runs before every action
One filter runs on all 20 actions. There is no action that skips it.
It requires a guardian's own id on every single request; missing or malformed, and the request fails immediately, before anything else runs. It then reads the stored sign-in id for that guardian and compares it with whoever is actually signed in. If it is blank, or does not match, or belongs to another organisation, the request is refused with the exact same message every time, deliberately, with no way to tell those cases apart from the outside.
Can a guardian reach another family's child?
No. Two independent checks stand in the way, and both were verified.
The filter above proves the guardian owns the account they claim to. Every single action that names a specific child then checks, separately, that this exact guardian is actually linked to this exact child, and refuses the request if not. This was verified in all eleven actions that take a child's id.
Changing a child's id in a web address returns a refusal, not another family's child. This is the module's strongest positive finding, worth stating plainly since so little else in the module actually works.
Two exceptions sit beside it. Reading emergency alerts is scoped to the whole organisation, not to a guardian's own children or sites, so every guardian in an organisation would see every alert at every site if any alert could ever exist. And the live connection performs its own, different check, described below.
The 20 actions
A dash means nothing in the portal calls this action today.
Dashboard
| Action | Reachable by | Status |
|---|---|---|
| Read the dashboard | The Dashboard screen | Works. Children and today's check-in status are live. The three counters, unread messages, pending forms and unacknowledged alerts, are all structurally zero |
Child record
| Action | Reachable by | Status |
|---|---|---|
| Read a child's profile | Nothing reaches it | Built correctly |
| Read a child's attendance | Nothing reaches it | Built correctly, reads live check-in records directly, and would work |
| Read a child's schedule | Nothing reaches it | Returns a day of the week as free text, and a programme's start and end dates where times of day are expected |
| Read a child's weekly summary | Nothing reaches it | Only counts hours from records with a check-out. Returns every staff note for the week, including ones marked confidential |
Health and safety
None of these five has anything on a guardian's device that could call them.
| Action | Reachable by | Status |
|---|---|---|
| Read medications on site | Nothing reaches it | Would return real, active records |
| Read the medication log | Nothing reaches it | The underlying record can never exist, on the staff side either |
| Read emergency action plans | Nothing reaches it | Would return real plans |
| Read a child's incidents | Nothing reaches it | Filters on no status at all, so a draft incident would be returned, and returns the reporter's raw, unedited narrative |
| Read illness records | Nothing reaches it | Would return real records |
Messages
| Action | Reachable by | Status |
|---|---|---|
| Read messages | The Messages screen | Reachable, always empty. Only ever returns messages the guardian sent, and none can be created |
| Send a message | The Messages screen | Always fails. The screen sends a placeholder identifier where a real one belongs, and PTRS refuses the request before anything else runs |
Authorization forms
| Action | Reachable by | Status |
|---|---|---|
| Read pending forms | The Forms screen | Reachable, always empty. Nothing can create a form |
| Read completed forms | The Forms screen | Reachable, always empty. If a form existed it would list every linked child as having signed, not only the ones actually signed for |
| Sign a form | The Forms screen | Cannot be reached. Requires a published form, and none can exist |
| Read a form as a document | Nothing reaches it | Returns plain data rather than a document, and of the signature, only the time it was signed |
Emergency alerts
| Action | Reachable by | Status |
|---|---|---|
| Read alerts | Nothing reaches it | No alert can ever exist, so always empty. Scoped to the whole organisation, not to the guardian's own children |
| Acknowledge an alert | Nothing reaches it | Always fails. No alert can exist to acknowledge |
Settings and devices
| Action | Reachable by | Status |
|---|---|---|
| Save settings | Nothing reaches it | The Save Changes button shows a confirmation and calls nothing |
| Register a device for alerts | Nothing reaches it | No delivery method exists to consume the saved token anyway |
Summary
| Count | |
|---|---|
| Actions in this module | 20 |
| Reachable by a screen | 6 |
| Reachable by nothing | 14 |
| Of the six reachable, return real data | 1: reading the dashboard |
| Of the six: reachable but structurally empty | 3: messages, pending forms, completed forms |
| Of the six: always fail | 2: sending a message, signing a form |
Requests that always fail
| Request | Fails because |
|---|---|
| Any request with no guardian id attached | The ownership check refuses it immediately |
| Any request from a guardian whose account has no sign-in link set | Nothing in PTRS ever sets that link |
| Sending a message | The screen sends a placeholder value where a real staff id belongs |
| Signing a form | No published form can ever exist |
| Acknowledging an alert | No alert can ever exist |
| Any parent-portal request from a signed-in administrator | The server accepts a guardian account only, while PTRS itself admits all three |
What each save actually checks
There is no check of any kind on the guardian's own device anywhere in PTRS, so these are the only rules that exist at all.
| Action | Rules |
|---|---|
| Send a message | Guardian, staff member and child must all be set. The message itself is required, up to 5,000 characters |
| Sign a form | The form, guardian and child must all be set. The signature and the answers to the form's questions are not checked at all: a form can be signed with no signature and no answers |
| Save settings | The guardian must be set. Contact preference and language must both be one of PTRS's own recognised values. The notification preferences are stored exactly as sent, unchecked |
| Register a device | The guardian must be set. The device type is required, up to 50 characters, and checked against no fixed list. The push token is required, up to 500 characters |
| Acknowledge an alert | The alert and the guardian must both be set |
The two dropdowns on the Settings screen match what PTRS accepts
| Choice | Options offered | Match |
|---|---|---|
| Preferred Contact | Email, SMS, App, Phone | All four |
| Language | English, Spanish, Haitian Creole | All three |
That makes two modules running clean of this problem, after six mismatches in CACFP, five in Members and three in Health & Safety. Neither choice ever actually reaches the server in any case, since the save button behind them calls nothing.
The live connection
A real-time connection exists for this module, one of four PTRS maps in total.
It requires the same guardian role the server itself requires. On connecting, it finds the guardian by matching an email address instead of the sign-in link the rest of the module checks, a different mechanism from everywhere else in this module. A guardian can satisfy one check and fail the other.
Three kinds of message are published, and the same three are subscribed to on the receiving side, all three matching correctly. This is the first live connection in PTRS where the names line up on both ends at all.
Nothing is ever actually sent over it: the one piece of code that could publish a message has nothing calling it, so all three publishing paths are dead. And nothing on any guardian's device ever connects to listen for one either, so no guardian's device is ever actually there to receive anything in the first place.
One further detail survives even a fix to the two problems above: an emergency alert, if one could ever be sent, would be broadcast to every connected guardian in PTRS rather than to the guardians at the one site it concerns, even though the message carries that site's own id.
So this connection is complete, correctly secured, and correctly named on both ends, and connected by nobody at either end.
Related
Checked against PTRS on 7 September 2026.