Parent/guardian accounts: register once, book for one or more students #132

New Issue

2026-07-29T01:44:02Z

thatguygriff commented

2026-07-29 01:44:02 +00:00

Goal

A parent/guardian should be able to register once and manage lessons for one or more children, without each child needing their own login. Today registration only produces a student who books for themselves.

This is a net-new feature and needs design work before implementation — this issue is the starting point, not a finished spec.

Why it doesn't fit today

The plugin treats "the WordPress user" and "the student" as the same entity everywhere. student_id is a wp_users id on every table in src/Schema.php:

Table	Column
`us_lessons`	`student_id`
`us_payments`	`student_id`
`us_credits`	`student_id`
`us_group_enrollments`	`student_id`
`us_question_answers`	`student_id`
`us_policy_acceptances`	`student_id`
`us_group_access`	`student_id`

Booking, billing, credits, policy acceptance, and registration answers all resolve the current user id directly. Introducing a person who books on someone else's behalf touches every one of those.

Core design decision

How is a child represented?

A) Child is a real WP user, linked to a guardian. Least disruptive — student_id keeps meaning "a WP user", so lessons/payments/credits work unchanged. Needs a guardian↔student link (user meta or a us_guardians table), an account-less creation path (no email/password required for a child), and capability changes so a guardian can act as their children.
B) Child is a plain record in a new us_students table. Cleaner conceptually — decouples "student" from "login" — but every student_id in the schema changes meaning, and existing rows need migrating. Much larger blast radius.

Recommend starting from (A) unless there's a reason children need their own logins later, in which case the migration path from A to B should be sketched before committing.

Questions to settle

Registration

Is "I'm registering as a parent/guardian" a checkbox on the signup form, or a separate flow?
Are children added during signup, or after, from an account screen?
What is collected per child — name, date of birth, anything else?
Do the account-scoped registration questions (Registration\Question, SCOPE_ACCOUNT) get asked once per guardian, or once per child? Some are clearly per-child.
Can a guardian also be a student themselves (booking their own lessons alongside their kids')?
Can two guardians share the same child (separated parents, both need visibility)?

Policies

Who accepts signup policies — the guardian, on behalf of each child? us_policy_acceptances.student_id currently records the person who clicked. Legally this is probably "guardian accepts for child" and should be recorded as such.

Booking

The booking page needs a "who is this lesson for?" selector.
Cancellation and the cancellation cutoff apply per lesson — presumably unchanged.

Payments and credits

Are payments and credits held against the guardian, the child, or the child with the guardian as payer? This determines the payment reporting and scheduled-billing changes.
Does a family share one credit balance, or one per child?
Sibling/family discounts — out of scope for v1, but worth not designing them out.

Admin

Students list should show the guardian relationship and let admins navigate between them.
Student detail (templates/admin/student-detail.php) needs the family context.
Can an admin create/attach a child to an existing guardian account?

Instructor view

Lesson lists show the student's name; the guardian's contact details are what an instructor actually needs to reach them.

Suggested first slice

Once the questions above are answered, a minimal first cut:

Guardian↔child data model + repository, with children as accountless linked accounts.
"Register as a parent" path that captures at least one child.
Manage-children screen on the guardian's account (add / edit / remove).
Student selector on the booking page; lessons record the child as student_id.
Payments and credits attributed per the decision above, with the guardian as payer.
Admin students list and detail showing the relationship.

Group class enrolment, family discounts, and multi-guardian sharing can follow.

Deliverables

docs/features/parent-guardian-accounts.md written first (per CLAUDE.md step 1), covering the data model and the decisions above.
Schema change → bump Version: header and USC_VERSION in unsupervised-schedular.php, or dbDelta never runs on existing sites.
Unit tests mirroring the new package under tests/Unit/.

## Goal A parent/guardian should be able to register once and manage lessons for **one or more children**, without each child needing their own login. Today registration only produces a student who books for themselves. This is a net-new feature and needs design work before implementation — this issue is the starting point, not a finished spec. ## Why it doesn't fit today The plugin treats "the WordPress user" and "the student" as the same entity everywhere. `student_id` is a `wp_users` id on every table in `src/Schema.php`: | Table | Column | |---|---| | `us_lessons` | `student_id` | | `us_payments` | `student_id` | | `us_credits` | `student_id` | | `us_group_enrollments` | `student_id` | | `us_question_answers` | `student_id` | | `us_policy_acceptances` | `student_id` | | `us_group_access` | `student_id` | Booking, billing, credits, policy acceptance, and registration answers all resolve the current user id directly. Introducing a person who books on someone else's behalf touches every one of those. ## Core design decision **How is a child represented?** - **A) Child is a real WP user, linked to a guardian.** Least disruptive — `student_id` keeps meaning "a WP user", so lessons/payments/credits work unchanged. Needs a guardian↔student link (user meta or a `us_guardians` table), an account-less creation path (no email/password required for a child), and capability changes so a guardian can act as their children. - **B) Child is a plain record in a new `us_students` table.** Cleaner conceptually — decouples "student" from "login" — but every `student_id` in the schema changes meaning, and existing rows need migrating. Much larger blast radius. Recommend starting from **(A)** unless there's a reason children need their own logins later, in which case the migration path from A to B should be sketched before committing. ## Questions to settle **Registration** - Is "I'm registering as a parent/guardian" a checkbox on the signup form, or a separate flow? - Are children added during signup, or after, from an account screen? - What is collected per child — name, date of birth, anything else? - Do the account-scoped registration questions (`Registration\Question`, `SCOPE_ACCOUNT`) get asked once per guardian, or once per child? Some are clearly per-child. - Can a guardian also be a student themselves (booking their own lessons alongside their kids')? - Can two guardians share the same child (separated parents, both need visibility)? **Policies** - Who accepts signup policies — the guardian, on behalf of each child? `us_policy_acceptances.student_id` currently records the person who clicked. Legally this is probably "guardian accepts for child" and should be recorded as such. **Booking** - The booking page needs a "who is this lesson for?" selector. - Cancellation and the cancellation cutoff apply per lesson — presumably unchanged. **Payments and credits** - Are payments and credits held against the guardian, the child, or the child with the guardian as payer? This determines the payment reporting and scheduled-billing changes. - Does a family share one credit balance, or one per child? - Sibling/family discounts — out of scope for v1, but worth not designing them out. **Admin** - Students list should show the guardian relationship and let admins navigate between them. - Student detail (`templates/admin/student-detail.php`) needs the family context. - Can an admin create/attach a child to an existing guardian account? **Instructor view** - Lesson lists show the student's name; the guardian's contact details are what an instructor actually needs to reach them. ## Suggested first slice Once the questions above are answered, a minimal first cut: 1. Guardian↔child data model + repository, with children as accountless linked accounts. 2. "Register as a parent" path that captures at least one child. 3. Manage-children screen on the guardian's account (add / edit / remove). 4. Student selector on the booking page; lessons record the child as `student_id`. 5. Payments and credits attributed per the decision above, with the guardian as payer. 6. Admin students list and detail showing the relationship. Group class enrolment, family discounts, and multi-guardian sharing can follow. ## Deliverables - `docs/features/parent-guardian-accounts.md` written first (per CLAUDE.md step 1), covering the data model and the decisions above. - Schema change → bump `Version:` header **and** `USC_VERSION` in `unsupervised-schedular.php`, or `dbDelta` never runs on existing sites. - Unit tests mirroring the new package under `tests/Unit/`. ## Related Touches: `docs/features/account-registration.md`, `lesson-booking.md`, `payments.md`, `credits.md`, `group-classes.md`, `student-administration.md`, `policies.md`, `registration-questions.md`.

thatguygriff added the feature label 2026-07-29 01:44:02 +00:00

thatguygriff referenced this issue from a commit

2026-07-29 19:00:42 +00:00

Let parents register once and book for their children

thatguygriff referenced a pull request that will close this issue

2026-07-29 19:01:40 +00:00

Let parents register once and book for their children #139

thatguygriff referenced this issue from a commit

2026-07-29 19:08:11 +00:00

Let parents register once and book for their children

thatguygriff closed this issue

2026-07-29 19:17:06 +00:00