Skip to main content

Work the cohort and consent screens

Both tabs let you create the container and neither lets you put anything in it. This page says which controls actually work, so you can use those, and stop looking for the ones that do not exist.

Cohorts​

What works: creating a cohort​

  1. Open the program's Cohorts tab.
  2. Press New Cohort.
  3. Enter a Name, for example Monday Group, an optional Description, and an optional Max Size. Leave Max Size empty for no limit.
  4. Press Create.
There is no length check on this form

The only limits are the size of the underlying storage: 200 characters for the name and 1,000 for the description. Going over either produces a plain server error rather than a helpful message. Max Size accepts zero and negative numbers with no complaint.

What does not work: putting anybody in one​

Adding a child to a cohort, and removing one, are both built correctly on the server, and neither has any control anywhere that calls it. There is no button on this tab, or anywhere else, that puts a child into a cohort.

So the consequences run through the whole tab:

  • every cohort card reads 0 members, permanently;
  • the Members in Cohorts tile reads 0;
  • the Avg per Cohort tile reads 0;
  • the capacity bar under a cohort with a Max Size is always empty;
  • a child's cohort column on her own Programs tab is always blank.

There is also no way to rename, describe, resize or delete a cohort once it is created.

For someone integrating directly

Adding a child to a cohort works correctly against the server: it enforces the cohort's Max Size, refuses a duplicate, and links the child's enrolment to the cohort. It does not check that the enrolment actually belongs to the cohort's own program, so validate that pairing yourself before sending the request.

What works: creating a form​

  1. Open the program's Consent tab, Forms sub-tab.
  2. Press New Form.
  3. Enter a Title, for example Photo/Video Release, and the full Form Content.
  4. Leave Required for enrollment on, or turn it off for an optional form.
  5. Press Create.
There is no length check here either

Title is limited to 250 characters by the underlying storage, with no earlier warning; going over it is a plain server error. Form Content has no limit at all.

The green tick on a form card means nothing

Every form card shows a green tick beside its response count, whether that count is 0 or 40. It is a fixed icon, not a real status.

The Pending sub-tab lists one row per active or waitlisted child, per active form with no record on file, the queue this tab exists to work through. Each row has a Record button that opens a proper signing dialog: grant or deny, a drawable signature, an optional expiry date, and it always fails. The screen sends a blank guardian identifier, so PTRS refuses the request before anything can be saved. An error message appears and the row stays in the queue.

Two more things about the same dialog:

  • The form's actual wording is not shown in it either, so a guardian would be asked to sign something they cannot read on screen.
  • The Guardian field always reads the fixed word "Guardian". There is no guardian picker anywhere on this tab.

So a signed consent for a specific program can never actually be recorded, the Pending queue never shrinks, and the Pending Consent tile on the Enrollment tab never falls.

What does not work: correcting a form​

Editing a consent form is built correctly and reachable from no screen. A form cannot be corrected once created, and it cannot be turned off either: the Inactive badge on a form's card describes a state nothing in the product can set.

If editing is ever wired up, know what it does

Every save increases the form's version number, and a recorded consent points at the form itself, not at a specific version of it. Editing a form after guardians have already signed would leave no record of the wording they actually agreed to.

The pending queue ignores expiry​

The pending list treats any existing record as settled, whether it granted or denied consent and whatever its expiry date says. A consent recorded with an expiry date that has since passed still counts as collected and never returns to the queue.

This is the part most likely to mislead a colleague, so it is worth stating on its own.

A child's enrolment carries its own consent status, starting at Pending. No code in PTRS ever moves it away from that starting value. Recording a consent on this tab saves the consent record and never touches that separate status.

It is read in three places, including the Programs tab on a child's own record. So that tab shows Pending for every program, for every child, permanently, and would go on doing so even if the Record button were fixed tomorrow.

Do not assume a consent recorded in one place is visible in the other.

MembersPrograms
WhereThe child's Overview tabThe program's Consent tab
Scoped toThe childA specific consent form on a specific program
Working?YesNo, the failure above

There are two separate pieces of code in PTRS both meant to record a consent, one belonging to each module, pointing at different tables. If you are reading the underlying code, check which module's file the piece you are looking at actually belongs to.

What you can do instead, today​

If a signed consent has to be on file for a child in a program, record it against the child rather than the program:

  • Use the child's Overview tab to record a consent, which works and is documented in Work a child's record.
  • Upload the signed form to the child's Documents tab.

Neither will clear the program's Pending queue or change the Pending Consent tile, because nothing connects the two records to each other. Say so in a note if a colleague is relying on that tile.

Where to go next​

Checked against PTRS on 7 September 2026.