Ask who the signup is for as a three-way choice
CI / Tests (PHP 8.2) (pull_request) Successful in 50s
CI / PHPStan (pull_request) Successful in 2m53s
CI / Coding Standards (pull_request) Successful in 2m57s
CI / Tests (PHP 8.1) (pull_request) Successful in 45s
CI / No Debug Code (pull_request) Successful in 2s
CI / Tests (PHP 8.3) (pull_request) Successful in 2m40s
CI / Build Plugin Zip (pull_request) Skipped
CI / Tests (PHP 8.2) (pull_request) Successful in 50s
CI / PHPStan (pull_request) Successful in 2m53s
CI / Coding Standards (pull_request) Successful in 2m57s
CI / Tests (PHP 8.1) (pull_request) Successful in 45s
CI / No Debug Code (pull_request) Successful in 2s
CI / Tests (PHP 8.3) (pull_request) Successful in 2m40s
CI / Build Plugin Zip (pull_request) Skipped
Replaces the single "I'm registering as a parent or guardian" tick with "Just myself" / "On behalf of one or more students" / "Both". Radios, not checkboxes as the feedback put it: the three answers are mutually exclusive, and "both" only means anything as a third choice alongside the other two. The tick could only ever say whether there were children to add. It could not say whether the account holder was a student, so bookableStudents() always offered them their own name and any guardian could book themselves a lesson nobody meant to sell. "On behalf of" now records us_guardian_only and leaves them out of the picker. That flag is stored as the negative on purpose. Every account predating this choice is a bookable student, and absence has to keep meaning exactly that, or the picker would quietly stop offering people themselves on upgrade. setGuardianOnly() clears the key rather than writing 0, so "not set" stays the single spelling of "yes, a student". A guardian-only account with nobody linked to it is still offered itself — an empty picker is no way to book at all, and they can put the account right from the profile page. An unrecognised or absent value reads as "just myself": the choice that collects the least and grants the least. A missing radio must never be taken as "register these children". Bumps to 1.4.0. The account holder's own questions stay out of play whenever students are being added, "both" included — asking them there is #146. Verified the form in a headless browser across all three choices: which blocks show, which fields carry `required`, whether the account holder's question panel is disabled, which submit is offered, and that switching back to "just myself" leaves no hidden required field blocking submit. Closes #145 Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
@@ -140,10 +140,43 @@ apply to.
|
||||
|
||||
## Registration
|
||||
|
||||
A **"I'm registering as a parent or guardian"** checkbox on the existing
|
||||
`[us_student_register]` form (all three signup paths — personal invite, group
|
||||
link, self-approval) reveals a repeatable child block. Ticking it requires at
|
||||
least one child name.
|
||||
A **"Who are you registering?"** choice on the existing `[us_student_register]`
|
||||
form (all three signup paths — personal invite, group link, self-approval), as
|
||||
three radios:
|
||||
|
||||
| Choice | `us_registering_for` | Student blocks | Account holder is a student |
|
||||
|---|---|---|---|
|
||||
| Just myself | `self` | no | yes |
|
||||
| On behalf of one or more students | `students` | yes | **no** |
|
||||
| Both — myself and one or more students | `both` | yes | yes |
|
||||
|
||||
Radios rather than checkboxes because the three answers are mutually exclusive:
|
||||
"both" only means anything as a third choice alongside the other two. Either
|
||||
student-bearing choice requires at least one student name.
|
||||
|
||||
Anything unrecognised — a form posted without the field, an old cached page, a
|
||||
crafted request — is read as `self`, the choice that collects the least and
|
||||
grants the least. A missing radio must never be taken as "register these
|
||||
children".
|
||||
|
||||
### The account holder as a student
|
||||
|
||||
This replaced a single "I'm registering as a parent or guardian" checkbox, which
|
||||
could only say *whether there were children to add*. It could not say whether the
|
||||
**account holder** was a student, so `bookableStudents()` always offered them
|
||||
their own name and every guardian could book themselves a lesson nobody intended
|
||||
to sell.
|
||||
|
||||
`students` now records `us_guardian_only = 1` and `bookableStudents()` leaves the
|
||||
account holder out. The flag is stored as the **negative** deliberately: every
|
||||
account predating the choice is a bookable student, and absence has to keep
|
||||
meaning exactly that, or the picker would silently stop offering people
|
||||
themselves on upgrade. `GuardianService::setGuardianOnly()` clears the key rather
|
||||
than writing `0`, so "not set" stays the one spelling of "yes, a student".
|
||||
|
||||
One guard: a guardian-only account with **nobody linked to it** is still offered
|
||||
itself, because an empty picker is no way to book at all. They can put the
|
||||
account right from the profile page.
|
||||
|
||||
Per child the form collects:
|
||||
- **Name** (required)
|
||||
|
||||
Reference in New Issue
Block a user