Who can do what on the dashboard

Who is admitted

This screen owns nine actions of its own, and all nine share one rule.

Group	Actions	Rule
The dashboard's own reads	9	Staff, a site director, a regional director, an organisation administrator or a super admin

Not one of the nine narrows or widens that rule further, and not one is open to anyone who has not signed in. That makes this the flattest set of rules anywhere on this documentation site: one shared rule is the entire story, with nothing layered on top of it anywhere.

The nine reads

Every one only reads; none of the nine ever changes anything. Every one also accepts an optional site, and nothing calling any of them actually sends one. See the site filter.

Read	What it returns	Reachable by
Ratio readings	The latest reading per site: children, staff, actual ratio, required ratio, and a status worked out from the compliance flag	10 different screen pieces across 4 areas
Attendance history	The 30 most recent daily summary rows, newest first	The attendance trend chart, the headline tiles
Today's attendance	The 100 most recent check-in and check-out events, with member name, age, photo, site, method, verifying staff member, guardian name and notification state	8 different screen pieces
Expected members	Every member expected today with an arrival window and an arrived, pending or absent status	5 different screen pieces
Attendance timeline	Today's check-ins and check-outs grouped by hour and site, with a net change	4 different screen pieces
Streak leaders	The top 10 members by consecutive attendance days	The child detail drawer opened from Attendance; the dedicated panel for this is not shown anywhere
Guardian notification log	The 50 most recent sent notifications, with guardian name and phone	The activity feed, the child detail drawer
Sites	Every active site with address, capacity, current headcount, staff on duty, compliance score, an operating status, director name and coordinates	13 different screen pieces across 4 areas
Members	Every member in the organisation with name, age, grade, date of birth, enrolment date, photo and status, with no limit on how many at once	The child detail drawer

Summary

	Count
Reachable from a screen	9
Not reachable from any screen	0
Total	9

This is the second module documented with no unreachable actions at all, after User Management's ten of ten. The nine here are used by more than twenty different screen pieces spread across attendance, compliance, this screen itself, the child record and the financial report, which is why: they were each built for a screen that actually uses them.

The closest to unused is the streak-leaders read. Its own dedicated panel is not shown anywhere, and it is still reached by the child detail drawer opened from the Attendance screen.

The site filter is never actually sent

Every one of the nine accepts an optional site to filter by. Every screen piece that calls one of them reads the selected site from shared state and puts it only into its own remembered-results key, then asks for the exact same information regardless of which site is selected.

Changing site therefore changes which remembered copy of the results you are looking at; it never actually changes what was asked for.

Five panels work around this by filtering the results themselves after the fact: the headline tiles, the site overview, the ratio banner, expected vs actual, and the welcome banner. Two, the activity feed and the attendance trend chart, do not, and both were already working from a list capped well below the whole organisation to begin with, so filtering after the fact would not have been enough in any case.

Requests that cannot come back with a useful answer

Two of the nine come back successfully with something that is structurally empty, and neither looks like a failure.

Request	What comes back	Why
Attendance history	Nothing	It reads from a table meant to be filled in overnight. Nothing anywhere in PTRS currently writes to it
Guardian notification log	Nothing	It reads from the notification log. PTRS has never sent a notification of any kind

A third, expected members, returns a plausible-looking list built from the wrong group of people when a site has no program schedules set up. See the panel page.

The seventeen panels, and where each one actually gets its figures

The home screen shows these in four visual groups. Only four of the seventeen read this screen's own figures alone.

Panel	Reads from	Module
Ratio Violation Banner	This screen's own ratio reading	Dashboard
Welcome Banner	This screen's own site list, your own account	Dashboard
Urgent Action Strip	Allergy alerts, credential expiry, document renewal, coverage gaps, pending background checks, this screen's own site list	Health & Safety, Staff, Centers, Dashboard
Headline tiles	This screen's own site list, ratio reading and attendance history; the compliance summary; the incident list; training compliance	Dashboard, Compliance, Incidents, Staff
Compliance by Location	The compliance summary	Compliance
Location Overview	This screen's own site list and ratio reading; the compliance summary	Dashboard, Compliance
Activity Feed	This screen's own today's-attendance and notification-log reads, and shared attendance state	Dashboard
Attendance Trend Chart	This screen's own attendance history and site list	Dashboard
Expected vs Actual	This screen's own expected-members and today's-attendance reads	Dashboard
Credential Expiry Timeline	Credential expiry alerts, pending background checks	Staff
CACFP Meal Service Status	Today's claim, meals with alerts, allergy alerts, this screen's own site list	CACFP, Health & Safety, Dashboard
Incident Velocity	Incident trends, the incident list	Incidents
Recent Incidents	The incident list	Incidents
OCCL Deadline Countdown	The incident summary, the incident list	Incidents
Staff Readiness	Credential expiry alerts, active onboarding, training compliance	Staff
Expiring Licences	The site summary	Centers
Compliance Trend	The compliance trend	Compliance

Three panels that are built and shown nowhere

Three built, working panels are not shown on the home screen or anywhere else: a streak-leaders panel duplicating what the child detail drawer already reads, a meal-program panel duplicating the CACFP panel that is shown, and a program-snapshot panel.

The last of the six live-update connections

This screen's own live-update connection admits any signed-in account of any role, including a guardian or a read-only account. On connecting, it places the account into one group per site it can reach.

What can be sent over it

Six different sources can send a message across this connection.

Message	Sent by	Reaches	Does it ever actually fire?
A feed event	Attendance check-in and check-out (3 places), the compliance engine, three OCCL deadline checks	A site group for the attendance ones, everyone for the rest	Yes
A location-status event	The check-in and check-out actions	A site group	Yes
A location-status event	A second, dashboard-specific sender	Everyone	No, nothing calls that sender
A KPI-update event	The same dashboard-specific sender	Everyone	No, nothing calls that sender at all
An emergency-alert event	The Parent Portal's sender	Everyone	No, nothing calls that sender, and nothing listens for it either
Regulation loading progress and completion	The regulation loader	Everyone	Yes

What the browser actually listens for

Listener	Messages
The home screen and the CACFP live feed	The KPI-update, feed and location-status messages
The regulation library screen	The two regulation loading messages

Five of the six messages are listened for. Three of those five can actually fire.

Why this connection is different from PTRS's other five

Connection	Messages it can send	Messages listened for	Any message that both fires and is heard
The attendance connection	3, and none of the three is ever actually sent	1	No
The compliance connection	13	8	No overlap at all
The parent connection	3	3, all matching	No, the sender is never actually called
The CACFP connection	3	Not connected at all	No, this connection is not even wired up
This connection	6	5	Yes, four of them
Total documented			6 of 6

The site grouping mostly goes unused

This connection places each account into a group per site, and five of the six senders broadcast to everyone rather than to that group. Only the attendance sender actually targets the group.

So a feed event from the OCCL check or the compliance engine, and a location-status event carrying a site name, headcount, ratio and compliance score, reach every connected account of every organisation sharing this installation.

The file meant to describe this screen's shapes, and largely does not

One file declares nine record shapes for this screen's own reads. Eight of the nine are never actually used; eight of the nine reads build their own, separate shape instead and send that.

Declared shape	Used?	What actually gets sent
The check-in event shape	Yes	The same shape
The attendance history shape	No	A different shape, whose site field is a genuine identifier rather than plain text
The timeline entry shape	No	A different shape
The streak leader shape	No	A different shape
The guardian notification shape	No	A different shape, whose sent time is plain text rather than a real date and time
The site shape, 8 fields	No	A different, same-named shape with 18 fields
The member shape, with a name field, a site field and an allergy flag	No	A different, same-named shape with separate first and last name, no site field and no allergy flag
The expected-member shape, whose arrival time is a real date and time	No	A same-named shape whose arrival time is plain text instead
No shared version exists		The ratio shape

Three names are declared twice over, in the same collection of code, told apart only by which part of it they live in.

This matters because reading only the file named for this screen's own shapes gives the wrong field names, a missing site field, and the wrong kind of value for a sent time, and that is exactly the mistake the screen-side type declarations make too. See below.

What the screen expects against what actually arrives

Six of eight screen-side type declarations match what actually arrives exactly. Two do not.

Declared as	Verdict
The check-in event	Matches field for field
Daily attendance	Matches
The ratio reading	Matches, including all three status words
The expected member	Matches, including all three status words
The streak leader	Matches
The guardian notification	Matches
The site	Declares an operating-hours shape and a coordinates shape that do not match what is actually sent; nothing on this screen reads either field anyway
The member	Declares a site field, programs, allergies, emergency contacts, guardian ids and an attendance streak. None of the six is actually sent

The member mismatch is the one that matters. The child detail drawer, the only screen piece that reads this screen's own member list, reads both the site field and the attendance streak in several places. Most of those reads are guarded against a missing value; two are not, and one of those two is what the drawer's own Check Out control needs in order to find the session it is meant to close.

Every one of this screen's own results is force-cast to a type before use, so none of the mismatches above would ever be caught automatically.

What is remembered, and for how long

Read	Behaviour
Ratio readings	Refreshed automatically every 30 seconds
Today's attendance	Refreshed automatically every 30 seconds
The other seven	Fetched once per remembered key; never refreshed automatically
Any live event	Clears every remembered result for this screen at once

None of the nine reads is remembered on the server itself. The sites read looks at three separate record types on every single call, and the streak leaders read pulls every check-in the organisation has ever recorded into memory, with no date limit at all.