unsupervised-scheduler

Unsupervised/unsupervised-scheduler

Fork 0

Author	SHA1	Message	Date
thatguygriffandClaude Opus 5	1d2f95d388	Require a name and birth year for every student CI / Tests (PHP 8.1) (pull_request) Successful in 42s Details CI / Coding Standards (pull_request) Successful in 2m56s Details CI / PHPStan (pull_request) Successful in 2m56s Details CI / Tests (PHP 8.2) (pull_request) Successful in 50s Details CI / No Debug Code (pull_request) Successful in 2s Details CI / Tests (PHP 8.3) (pull_request) Successful in 2m45s Details CI / Build Plugin Zip (pull_request) Skipped Details Both fields are marked in their labels the same way a required registration question is, and enforced on the server whichever form they arrive from: GuardianService::createChild() and updateChild() now refuse a blank name or an unusable birth year, and the signup form checks the same rule up front, before it creates a single user, so a bad block never leaves a half-registered family behind. normaliseBirthYear() became public and static so both paths share one definition of what a usable year is. The signup form cannot lean on the browser here. Its child blocks are hidden until the parent/guardian box is ticked, and a `required` field inside a hidden container makes the whole form unsubmittable with no control the user can reach to fix — the same trap the guardian's own question panel already sidesteps by disabling rather than hiding. So register.js puts `required` on and takes it off along with the block itself, and the server is what makes the rule hold with JavaScript off. The profile screen has no such problem: its forms are always visible, so the attribute is static there. One behaviour change beyond the requirement: a child block with anything typed into it is now reported back instead of dropped. Previously any block without a name was silently discarded, which would now mean losing a birth year the guardian had filled in. A wholly untouched spare block — the one the form always renders for "add another" — is still ignored. Verified the required-toggling in a headless browser: unticked submits, ticked blocks an empty block, a cloned block inherits the requirement, and re-unticking leaves nothing behind to block a non-guardian signup. Closes #148 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-29 21:00:45 -03:00
thatguygriff	2878beb221	Merge pull request 'Collect a birth year instead of a full date of birth' (#153 ) from feature/147-birth-year into main CI / Tests (PHP 8.2) (push) Successful in 50s Details CI / Tests (PHP 8.1) (push) Successful in 52s Details CI / No Debug Code (push) Successful in 2s Details CI / PHPStan (push) Successful in 2m47s Details CI / Build Plugin Zip (push) Successful in 2m35s Details CI / Coding Standards (push) Successful in 2m58s Details CI / Tests (PHP 8.3) (push) Successful in 2m44s Details Reviewed-on: #153	2026-07-29 23:53:37 +00:00

Author

SHA1

Message

Date

thatguygriffandClaude Opus 5

1d2f95d388

Require a name and birth year for every student

CI / Tests (PHP 8.1) (pull_request) Successful in 42s

Details

CI / Coding Standards (pull_request) Successful in 2m56s

Details

CI / PHPStan (pull_request) Successful in 2m56s

Details

CI / Tests (PHP 8.2) (pull_request) Successful in 50s

Details

CI / No Debug Code (pull_request) Successful in 2s

Details

CI / Tests (PHP 8.3) (pull_request) Successful in 2m45s

Details

CI / Build Plugin Zip (pull_request) Skipped

Details

Both fields are marked in their labels the same way a required registration
question is, and enforced on the server whichever form they arrive from:
GuardianService::createChild() and updateChild() now refuse a blank name or
an unusable birth year, and the signup form checks the same rule up front,
before it creates a single user, so a bad block never leaves a
half-registered family behind. normaliseBirthYear() became public and static
so both paths share one definition of what a usable year is.

The signup form cannot lean on the browser here. Its child blocks are hidden
until the parent/guardian box is ticked, and a `required` field inside a
hidden container makes the whole form unsubmittable with no control the user
can reach to fix — the same trap the guardian's own question panel already
sidesteps by disabling rather than hiding. So register.js puts `required` on
and takes it off along with the block itself, and the server is what makes
the rule hold with JavaScript off. The profile screen has no such problem:
its forms are always visible, so the attribute is static there.

One behaviour change beyond the requirement: a child block with anything
typed into it is now reported back instead of dropped. Previously any block
without a name was silently discarded, which would now mean losing a birth
year the guardian had filled in. A wholly untouched spare block — the one
the form always renders for "add another" — is still ignored.

Verified the required-toggling in a headless browser: unticked submits,
ticked blocks an empty block, a cloned block inherits the requirement, and
re-unticking leaves nothing behind to block a non-guardian signup.

Closes #148

Co-Authored-By: Claude Opus 5 <[email protected]>

2026-07-29 21:00:45 -03:00

thatguygriff

2878beb221

Merge pull request 'Collect a birth year instead of a full date of birth' (#153 ) from feature/147-birth-year into main

CI / Tests (PHP 8.2) (push) Successful in 50s

Details

CI / Tests (PHP 8.1) (push) Successful in 52s

Details

CI / No Debug Code (push) Successful in 2s

Details

CI / PHPStan (push) Successful in 2m47s

Details

CI / Build Plugin Zip (push) Successful in 2m35s

Details

CI / Coding Standards (push) Successful in 2m58s

Details

CI / Tests (PHP 8.3) (push) Successful in 2m44s

Details

Reviewed-on: #153

2026-07-29 23:53:37 +00:00

Compare commits

Diff Content Not Available