Let the account holder edit their own details on the profile page #166

2026-07-30T18:13:45Z

thatguygriff commented

2026-07-30 18:13:45 +00:00

Closes #165.

What changes for a visitor

The Profile block ([us_family]) is headed "Your profile", but the one person on it you could not change was yourself. A Your details section now opens the page, above your students:

Your name (required).
I take lessons myself — the positive of us_guardian_only. Ticking it makes you bookable again and asks for your birth year like any other student; unticking it takes you off the picker.
Your birth year, held to the same normaliseBirthYear() rule as every student.

Your email is shown but not editable: it is the account's user_login as well as its address, so changing it stays a studio-side job.

The second bullet is the one that was actually blocking people. That flag is set once by the "Who are you registering?" radio at signup and decides whether you are offered as a student when booking — so picking wrongly, or taking up lessons later alongside the children you book for, meant asking the studio to fix it. GuardianService::bookableStudents() and docs/features/parent-guardian-accounts.md both already claimed such an account "can put itself right from the profile page"; this makes that true.

Implementation

GuardianService::accountHolder() — name, email, birth year and is_student, the counterpart to children() for the person reading the page.
GuardianService::updateSelf() — writes display_name and nickname together, for the reason updateChild() does: UserName reads the nickname first, and leaving it behind would put the account's email address back on every screen that names a person.
FamilyPage handles a new self action through the same nonce-checked template_redirect post/redirect/get path as add/edit/remove, with its own confirmation notice. No new capability, no new REST surface, no schema change — hence no version bump.
BlockPreview::family() updated, since the editor preview is what someone placing the block styles against and it was showing a page that no longer exists.

Two decisions worth a look

The birth-year field carries no required attribute. It is asked of a student only, and this page loads no JavaScript, so a browser-enforced required would leave a guardian who books solely for other people unable to submit the form at all. handleSelf() enforces it against the checkbox instead, which is where the condition actually lives.
Unticking "I take lessons myself" does not clear a stored birth year. The box says who books, not "forget what you know about me", and someone who ticks it back on next visit should find their details as they left them.

Not included

The account-scope registration questions are not re-asked here, in either direction. The child rows do not offer them on edit either, so doing it only for the account holder would have been the odd one out — but it does mean a guardian who newly declares themselves a student has no answers on file. Happy to follow up if you would rather they were prompted.

Tests

composer test — 907 tests, 2572 assertions, all passing (new coverage in FamilyPageTest, GuardianServiceTest, BlockPreviewTest — which had no family() coverage at all before).
composer lint — no errors.
composer cs — clean.

Rebased onto main at 1.5.0 after #164 merged; the changelog bullets sit alongside that one under the same heading.

🤖 Generated with Claude Code

Closes #165. ## What changes for a visitor The **Profile** block (`[us_family]`) is headed "Your profile", but the one person on it you could not change was yourself. A **Your details** section now opens the page, above your students: - **Your name** (required). - **I take lessons myself** — the positive of `us_guardian_only`. Ticking it makes you bookable again and asks for your birth year like any other student; unticking it takes you off the picker. - **Your birth year**, held to the same `normaliseBirthYear()` rule as every student. Your **email** is shown but not editable: it is the account's `user_login` as well as its address, so changing it stays a studio-side job. The second bullet is the one that was actually blocking people. That flag is set once by the "Who are you registering?" radio at signup and decides whether you are offered as a student when booking — so picking wrongly, or taking up lessons later alongside the children you book for, meant asking the studio to fix it. `GuardianService::bookableStudents()` and `docs/features/parent-guardian-accounts.md` both already claimed such an account "can put itself right from the profile page"; this makes that true. ## Implementation - `GuardianService::accountHolder()` — name, email, birth year and `is_student`, the counterpart to `children()` for the person reading the page. - `GuardianService::updateSelf()` — writes `display_name` **and** `nickname` together, for the reason `updateChild()` does: `UserName` reads the nickname first, and leaving it behind would put the account's email address back on every screen that names a person. - `FamilyPage` handles a new `self` action through the same nonce-checked `template_redirect` post/redirect/get path as add/edit/remove, with its own confirmation notice. No new capability, no new REST surface, no schema change — hence no version bump. - `BlockPreview::family()` updated, since the editor preview is what someone placing the block styles against and it was showing a page that no longer exists. ## Two decisions worth a look - **The birth-year field carries no `required` attribute.** It is asked of a student only, and this page loads no JavaScript, so a browser-enforced `required` would leave a guardian who books solely for other people unable to submit the form at all. `handleSelf()` enforces it against the checkbox instead, which is where the condition actually lives. - **Unticking "I take lessons myself" does not clear a stored birth year.** The box says who books, not "forget what you know about me", and someone who ticks it back on next visit should find their details as they left them. ## Not included The account-scope registration questions are not re-asked here, in either direction. The child rows do not offer them on edit either, so doing it only for the account holder would have been the odd one out — but it does mean a guardian who newly declares themselves a student has no answers on file. Happy to follow up if you would rather they were prompted. ## Tests - `composer test` — 907 tests, 2572 assertions, all passing (new coverage in `FamilyPageTest`, `GuardianServiceTest`, `BlockPreviewTest` — which had no `family()` coverage at all before). - `composer lint` — no errors. - `composer cs` — clean. Rebased onto `main` at 1.5.0 after #164 merged; the changelog bullets sit alongside that one under the same heading. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

thatguygriff added 1 commit 2026-07-30 18:13:45 +00:00

Let the account holder edit their own profile details

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

Details

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

Details

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

Details

CI / PHPStan (pull_request) Successful in 2m57s

Details

CI / Coding Standards (pull_request) Successful in 3m3s

Details

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

Details

CI / Build Plugin Zip (pull_request) Skipped

Details

f97b8a4576

The Profile block is headed "Your profile", but the one person on it you
could not change was yourself: your name, your birth year, and whether you
take lessons yourself were fixed at whatever signup recorded, and correcting
any of them meant asking a studio admin.

A "Your details" section now opens the page, saved through the same
nonce-checked template_redirect post/redirect/get path the child rows use:

- Your name, written to display_name and nickname together, for the reason
  updateChild() does — UserName reads the nickname first, and leaving it
  behind would put the account's email address back on every screen that
  names a person.
- "I take lessons myself", the positive of us_guardian_only. This makes good
  on the claim already in bookableStudents() and the feature doc that a
  guardian-only account can put itself right from the profile page.
- Your birth year, held to the same normaliseBirthYear() rule as every other
  student.

The email is shown but not editable: it is the account's user_login as well
as its address, so changing it stays a studio-side job.

The birth-year field deliberately carries no `required` attribute. It is
asked of a student only, and this page loads no JavaScript, so a
browser-enforced `required` would leave a guardian who books solely for
other people unable to submit the form at all; handleSelf() enforces it
against the checkbox instead. Unticking the box does not clear a stored
birth year — it says who books, not "forget what is on file".

Closes #165

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

thatguygriff merged commit 748478f2f1 into main

2026-07-30 19:29:22 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Unsupervised/unsupervised-scheduler#166