Who can do what with members and guardians
This page covers all 59 things PTRS can do in the Members module, the complete module on one page. 50 concern children and guardians directly; 9 belong to Quick Scan.
Every row states whether anything in the product actually calls it.
Who is admitted
Both groups of actions require the same setting:
Three actions diverge from the group, in both directions. This is the first module in this portal where both directions appear together.
| Action | Adds | Effective audience |
|---|---|---|
| Reading financial info | A second, narrower setting | Organisation administrators and super admins |
| Saving financial info | The same narrower setting | Organisation administrators and super admins |
| Reading the blank enrolment form | No sign-in check at all | Everyone, signed in or not |
A person must satisfy both settings to reach the financial actions. The narrower setting admits organisation administrators, regional directors and super admins; the module-wide one admits staff members, site directors, organisation administrators and super admins. Combined, only organisation administrators and super admins pass both. A regional director is excluded by the module-wide setting, and staff members and site directors are excluded by the narrower one. See Member financial information.
The blank form's check overrides rather than combines with anything else. It is the second such case found in PTRS, after the staff training catalogue. What it returns is a blank printable form with no child data; the detail is in the blank application form below.
One setting gates reading and saving together. A front-line staff account can create a child, edit any field on any child, add and remove a guardian, add and remove an authorised pickup, add and remove a restricted person, grant and revoke a consent, verify a document, delete a document and a note, and confirm a scan into a live record.
The same account reads her pickup password, her insurance policy number and every medical field, and reads notes marked "Confidential".
This is recorded for the PTRS team and is not being fixed as part of this guide.
How to read the "Reachable" column
| Value | Means |
|---|---|
| A screen | A page or component calls it in normal use |
| Nothing reaches it | The plumbing exists and no screen calls it |
| Called, always fails | A screen calls it on every use and the request can never succeed. The reason is given in the row |
Summary
| Count | |
|---|---|
| Total actions | 59 |
| Reached by a screen | 49 |
| Reached by nothing | 10 |
| Of those reached, always fail | 1 |
| Gated by the module-wide setting alone | 56 |
| Gated by the module-wide setting plus the financial setting | 2 |
| Open with no sign-in check | 1 |
| Save actions with no check on them at all | 4 |
| Checks that set a maximum length | 11 of 20 |
Finding and reading a child, and her audit history (6 actions)
| Action | Reachable by |
|---|---|
| Search by name | The module's own picker, used by the header's quick attendance entry and Health and Safety, and called directly by both Programs enrolment screens |
| Search, paged | The directory and all four of its alternative views |
| Read a child | Her own record page |
| Read her full record | Her own record page |
| Read her attendance streak | Her own record page |
| Read her audit history | The audit panel inside the edit sheet, not a section on the page |
The name search remembers its answer for 2 minutes. Creating or editing a child clears that memory only for the blank search term, so a search for a specific name keeps returning the pre-change result for up to two minutes after an edit.
The two searches match the same thing: first name or last name containing the lowercased term. Neither searches the organisation-assigned id, although the directory's placeholder reads "Search by name or member ID…".
Sorting only really works on two of five columns. PTRS handles first name, date of birth and enrolment date by name and falls back to last name for everything else. The directory sends name, age, grade, status and enrolment date as its five sortable columns, so three of the five sort by last name while showing the arrow on the column that was clicked.
The filters fare better. Status is checked against the values PTRS recognises; grade is matched exactly; minimum and maximum age are converted to a date-of-birth range and the arithmetic is correct.
The audit history is narrower than it looks, too. It only shows changes to the child's own record. Every other save in the module logs under its own category, guardian, emergency contact, authorised pickup, restricted person, consent, document, note, accommodation, demographic, structured medical record, financial record, enrolment, scanned application, and none of them appears on the child's audit history. Six fields on her main record are also excluded from the recorded values; see Member and guardian fields.
Creating and updating a child (3 actions)
| Action | Reachable by |
|---|---|
| Create a child | Quick Actions → Quick Member Entry, and the registration wizard's step 1 |
| Update a child | The edit sheet on her record |
| Read the server-rendered QR badge | Nothing. The browser builds its own QR code instead |
Creating checks five things: first name and last name required, up to 100 characters; date of birth and enrolment date required; the organisation required. Updating checks only three: the id, first name and last name.
There is no age rule, no date-range rule and no future-date rule on either. See Age and grade.
Creating a child and her guardian assigns the organisation whatever value was sent, after checking only that the signed-in account's own organisation has a value. The two are never compared to each other.
A child and a guardian can therefore be created into another organisation by sending its identifier. The same shape appears on recording a consent and updating demographics, both of which require an organisation on the request and neither of which checks it against the account that sent it.
Every other action in the module works out the organisation from the signed-in account instead.
The server-rendered QR badge is real and unused. PTRS can generate a scannable code containing the child's record id, and nothing calls it: the browser builds the same code itself, and the badge dialog builds a third, slightly different version. Three different builds of the same code, and the one PTRS itself renders is the one nothing uses.
Guardians (3 actions)
| Action | Reachable by |
|---|---|
| Link an existing guardian | Nothing reaches it |
| Create and link a guardian | The guardian list on the Overview tab |
| Edit a guardian | Nothing reaches it |
Linking an existing guardian is the better-built of the two: it checks the child is in the organisation, checks the guardian is in the organisation, refuses a duplicate link, and is the only path that would let two siblings share one guardian record. Nothing reaches it, and there is no screen that lists guardians to choose from.
Creating a guardian has no check on it at all. It is one of four save actions in the module with no rule class whatsoever, and its request treats email and phone as required text with no rule, so a blank value for either reaches the record's required field and produces a plain server error, not a helpful message.
Editing a guardian requires an id, first name, last name (both up to 100 characters) and phone. Email has no rule and no format check.
Emergency contacts, pickups and restricted persons (7 actions)
| Action | Reachable by |
|---|---|
| Add an emergency contact | Overview tab, Pickup Auth tab, wizard step 2 |
| Edit an emergency contact | Nothing reaches it |
| Remove an emergency contact | Overview tab, Pickup Auth tab |
| Add an authorised pickup | Overview tab, Pickup Auth tab, wizard step 4 |
| Remove an authorised pickup | Overview tab, Pickup Auth tab |
| Add a restricted person | Overview tab, Pickup Auth tab, wizard step 4 |
| Remove a restricted person | Overview tab, Pickup Auth tab |
What is checked here: Adding an emergency contact requires the child's id, first name (100), last name (100), phone, all required, and a priority of 1 or more. Editing one drops the priority rule. Adding an authorised pickup or a restricted person requires the child's id, first name (100), last name (100). There is no phone rule on a pickup, and no length rule on relationship, reason or notes.
Editing an emergency contact, removing an emergency contact, removing an authorised pickup and removing a restricted person all locate their row by its own id and the child's id alone. None checks the signed-in account's organisation, and none loads the child first.
The rule that normally protects a record from another organisation does not save them here: these four record types carry the rule that hides a removed row and skip the rule that scopes a row to an organisation.
Anyone holding both ids can therefore edit or remove another organisation's emergency contact or pickup authorisation. The matching add actions all check the child correctly, so the gap is on editing and removing only.
Removing also hides its own history. Removing an authorised pickup sets a revocation date and hides the row at the same time. Because the record is then excluded from every read, the revocation date can never be read back, and the person simply disappears from the list. There is no revocation history.
Consents (3 actions)
| Action | Reachable by |
|---|---|
| Read a child's consents | Nothing reaches it; the consent panel reads the copy inside her full record instead |
| Record a consent | The consent panel on the Overview tab, which works, and the wizard's step 6, which always fails |
| Revoke a consent | The consent panel |
Recording a consent requires the child's id, the organisation, the consent type and the signing guardian. Consent type is then checked against the 21 types PTRS recognises, and an unrecognised value fails the save.
The registration wizard identifies guardians with a temporary, made-up value invented in the browser and sends it where a real guardian identifier belongs. It is not a real id, so the request is refused before it is even read. Consents also carry a real, enforced link to a specific guardian record, so even a well-formed but non-existent id would fail at the point of saving instead.
The signature field is capped at 10,000 characters and nothing checks the length before sending, so a signature longer than that produces a plain server error rather than a helpful message.
The consent panel on the child's own record sends a real guardian identifier from her loaded record, and works.
Revoking a consent works correctly regardless, because a consent already carries the organisation check every record in this category needs.
Demographics and medical information (4 actions)
| Action | Reachable by |
|---|---|
| Read demographics | Nothing reaches it |
| Update demographics | Nothing reaches it |
| Read the structured medical record | Health tab |
| Save the structured medical record | Health tab, wizard step 3 |
Both saves create the row on first use and only apply the fields actually sent. Neither checks that the child exists or belongs to the signed-in account's organisation before creating a row against the given id.
Updating demographics only actually requires the child's id and the organisation. Saving the structured medical record only actually requires the child's id, with no length rule on any of its eighteen fields, several of which are free text.
The medical record and the screen disagree in both directions, too. The screen omits the allergies field from both its own types; it sends and reads a dietary restriction type, special medical needs and behavioural health notes, none of which PTRS's own record declares. All four fields exist underneath. Table in Member and guardian fields.
Documents (7 actions)
| Action | Reachable by |
|---|---|
| List a child's documents | Documents, Health and Accommodations tabs |
| Check for missing documents | Nothing reaches it |
| Upload a document | Documents tab, wizard step 7 |
| Download a document | Documents tab |
| Verify a document | Documents tab |
| Move a document's status | Nothing reaches it |
| Delete a document | Documents tab |
Upload limits are 25 MB, PDF, JPG, JPEG, PNG, GIF, DOC, DOCX. The file is optional; a document row can be created with details and no file. The check requires the child's id, document type and document name (up to 250 characters).
Document type is checked against 24 recognised names, and an unrecognised value fails the save. Three of the eleven types the registration wizard offers are not names PTRS recognises: School Enrollment Verification, Medical Form and IEP/504 Plan.
Verified by is free text from the request, not the signed-in account's actual identity. It is capped at 200 characters and required. There is no un-verify: once verified, nothing sets it back, so moving a document's status could push it back to Pending while it stays marked verified, and that action is reachable from no screen anyway.
Download needs no extra check beyond the module-wide setting, since documents already carry the standard organisation rule. It reads the file from where PTRS stores uploads and reports it missing when the row, the file location or the file itself cannot be found.
Notes (5 actions)
| Action | Reachable by |
|---|---|
| List a child's notes | Notes tab |
| Add a note | Notes tab |
| Edit a note | Notes tab |
| Delete a note | Notes tab |
| Pin or unpin a note | Notes tab |
Adding and editing both require content, up to 10,000 characters. There is no rule on the subject line. Note type, communication direction and communication method are checked; note type fails the save on an unrecognised value, the other two are dropped without a message.
The list shows pinned notes first, then newest first, and an unrecognised filter is ignored rather than refused, so a bad filter returns every note.
The confidential flag is set on create and update, returned on every read, and never actually used to filter a read. Any account holding the module-wide setting, including a front-line staff member, reads every note on every child, marked or not.
Accommodations (4 actions)
| Action | Reachable by |
|---|---|
| List accommodations | Accommodations tab |
| Add an accommodation | Accommodations tab |
| Edit an accommodation | Accommodations tab |
| Remove an accommodation | Accommodations tab |
Both save checks require what a child needs, up to 2,000 characters. Disability type and plan review date are checked and quietly dropped when unrecognised, on both create and update.
This is the one area of the module where all four actions are reachable from one screen and every one works.
Enrolment history (4 actions)
| Action | Reachable by |
|---|---|
| Read enrolment history | Financial tab, Programs tab |
| Read the current enrolment | Programs tab |
| Add an enrolment | Financial tab, wizard step 9 |
| Terminate an enrolment | Financial tab |
Adding an enrolment requires the child's id, enrolment type and two dates. Enrolment type and both dates are then checked, each failing the save on a bad value. Terminating requires the child's id, the enrolment id, a termination reason and a termination date, both checked.
Adding an enrolment is the module's real safety gate, and the most consequential action in it. Unless a waiver flag is set, it runs five checks in order and refuses on the first failure:
| # | Check | Reads |
|---|---|---|
| 1 | At least 2 emergency contacts, not removed | Her emergency contacts |
| 2 | An Emergency Hospitalization consent, granted, not revoked, not expired | Her consents |
| 3 | Immunisations marked exactly up to date | Her structured medical record |
| 4 | Last physical date within 1 year of today | Her structured medical record |
| 5 | Every emergency-type medication on site cleared to administer | Medications on site |
A sixth rule is a warning only: if her medical conditions text contains asthma, diabetes, seizure, allergy, anaphylaxis or epilepsy, in any case, and she has no active emergency action plan, the save still succeeds and PTRS quietly logs a warning. Nothing reads that warning, so it reaches nobody.
The 2 and the 1 year are printed with their source in Member and guardian fields, where the page also states that the code cites no regulation for either.
Checks 3 and 4 read her structured medical record. Quick Scan writes physician, hospital and insurance values onto her main record and never creates that structured record; Quick Member Entry collects no medical fields at all. Only the Health tab and the registration wizard write it.
So an enrolment for a scanned or quick-added child fails check 3 until somebody opens the Health tab and sets Immunizations Up to Date and a physical date.
A waiver flag exists on the request and no screen sets it, so the override cannot be used from the interface. The panel built to show all five checks and the waiver switch is reachable from no screen.
Program enrolments (1 action)
| Action | Reachable by |
|---|---|
| Read a child's program enrolments | Programs tab |
This reads the schedule, the programme and its site. This is the Programs module's own data; enrolling a child into a specific programme, and the licence-capacity check that runs when you do, happens over there, not here.
The blank application form (1 action)
| Action | Reachable by |
|---|---|
| Generate the blank enrolment form | Nothing reaches it |
Open with no sign-in check required.
What it returns is a blank form: six letter-size pages of empty fields and checkboxes, covering the child, guardian, emergency contacts and medical detail, accommodations and pickup, household and financial, consents, and agreements and signatures, branded for Boys and Girls Clubs of Delaware. It reads no child data and contains none, so the open access exposes a printable form and a document-building action, not personal information.
Two things are still true of it. The programme year is unchecked free text printed into the page header and into the downloaded file's name, defaulting to the current and following year from the server clock. And nothing in PTRS links to it, so the printable form staff are meant to hand out can only be reached by typing its address directly.
Quick Scan (9 actions)
Gated by the same module-wide setting, with no narrower rule and no open access on any of the nine.
| Action | Reachable by |
|---|---|
| Submit a single scan | Quick Scan drawer, single file |
| Submit a batch of scans | Quick Scan drawer, two or more files |
| Confirm a scan | Drawer compact review and the detailed review screen |
| Confirm a batch | Drawer batch summary, and Confirm Selected on the review queue |
| Reject a scan | Both review surfaces |
| List pending scans | The review queue |
| Read one scan | The detailed review screen |
| Read the scanned image | Called, always fails. Rendered as a plain picture with no sign-in carried, so PTRS refuses it |
| Read scan statistics | The Scan Stats widget on the review queue |
What is checked here: Submitting a scan requires a file, at most 10 MB, in one of seven accepted formats. Submitting a batch requires files, at most 20. Confirming requires the scan id and reviewer notes up to 2,000 characters. Confirming a batch requires the scan ids. Rejecting requires the scan id and a reason, required, up to 2,000 characters. The size and format rules are checked twice, once in the check itself and again where the save runs, with the same numbers both times.
Both listing actions scope by organisation explicitly, and the default status filter shows scans awaiting review unless another is chosen. Reading one scan and reading its image both look up by id alone and rely on the standard organisation rule, which does apply here.
The pipeline, the confidence figure and the confirm behaviour are documented in What Quick Scan extracts.
Reachable from no screen
Ten of 59. Each is built, checked where a check exists, and unreachable from any screen.
| Action | What is lost |
|---|---|
| Read the server-rendered QR badge | Nothing; the browser generates its own |
| Link an existing guardian | The only way to attach an existing guardian to a second child. Every family with more than one child ends up with duplicate guardian records |
| Edit a guardian | Thirteen guardian fields have no writer at all: employment, military service, work phone, maiden name and her own address |
| Edit an emergency contact | A contact cannot be corrected, only removed and re-added |
| Read a child's consents | Nothing; the panel reads the copy in her full record |
| Read demographics | Nothing; the card reads the copy in her full record |
| Update demographics | Household setting, family setting, sibling counts, household size and income range can display and never be entered |
| Check for missing documents | The document-completeness check has no screen |
| Move a document's status | A document's status can only change by being verified |
| Generate the blank enrolment form | The printable blank form is not linked from anywhere |
One screen calls a link that does not exist
The allergies panel on the Health tab calls a link that PTRS does not register at all. The function is wrapped so the failure is caught silently, and it is only called once, so the failure is invisible and the allergy list is permanently empty.
The structured allergy record behind it has four readers in other modules and no writer anywhere in the solution; see the module landing page.
Messages and counters
PTRS defines seventeen distinct error messages for this module with the right kind of refusal attached, including a duplicate-link message and five messages for the enrolment prerequisites. Only the five enrolment messages are ever actually shown; every other action returns a generic message instead, so twelve defined messages never appear in a response.
PTRS also defines five counters for this module. Four are never incremented: children created, guardians linked, documents uploaded and documents verified. The fifth, document expiry alerts checked, is incremented by the nightly document-expiry check and by a second component that would send a matching notice and is never actually switched on.
Where to go next
- Member and guardian fields, every field and its rule
- Member financial information, the two narrowed screens
- What Quick Scan extracts
- Members troubleshooting
Checked against PTRS on 7 September 2026.