Sweep the translatable strings across the frontend templates, the admin
screens, the editor previews and the block inserter entry. Nothing else
moves: the database columns, request parameters, form field names, CSS
classes, the us_family shortcode and the us-scheduler/family block name are
contracts with existing installs and with post content people have already
saved, so renaming them would break sites for no user-visible gain.
Two strings are reworded rather than swapped, because the direct
substitution reads wrong:
- The students list said "Child of Jane" and now says "Managed by Jane".
"Student of Jane" would read as a teacher's pupil, which is exactly the
wrong idea in a music studio.
- A managed account is now "a managed student account" rather than "a
student account", which would not distinguish it from the account holder.
The guardian feature doc gains a short section on the split, so the next
person to work on it does not read the mismatch as drift and "fix" it.
Closes#144
Co-Authored-By: Claude Opus 5 <[email protected]>
A parent registers once and manages lessons for one or more children, who
need no login of their own. A child is a real wp_users row with the student
role but no usable login — so student_id keeps meaning "a WordPress user"
on every table, and booking, credits, policies and enrolments work unchanged.
A us_guardians link table maps guardian to child.
The signup form gains a parent/guardian tick that reveals a block per child,
with the account-signup questions asked per child rather than per guardian
— they describe the student, not the account holder. Signup policies are
recorded once per child with the guardian as the acceptor, which is the
record that actually means something. A family that half-creates is rolled
back entirely rather than leaving a guardian who cannot re-register.
The booking and enrolment forms gain a "Who is this for?" picker listing
children first, so the default selection is never the parent — booking for
the wrong child is correctable, quietly billing a parent for their kid's
lesson is not. POST /bookings and POST /enrollments take an optional
student_id honoured only for that child's guardian; anything else is a 403.
That check is the authorisation boundary of the feature.
Payments and credits gain a payer: the charge names the child it was for and
the guardian who owes it, so per-child reporting is unchanged while notices,
receipts and the payment step reach the parent. Credit is held by the payer,
so one child's cancellation can settle a sibling's charge, and the daily
billing scan sends a guardian one notice covering every child.
Closes#132
Co-Authored-By: Claude Opus 5 <[email protected]>
Cancelling a lesson that was already paid for now credits the student
that money instead of leaving it as a manual refund, and the daily
scheduled-billing scan applies any available credit against their due
charges before emailing the notice.
- New us_credits ledger + us_payments.credit_applied column (Payment::netDue).
- PaymentService::creditForCancelledLesson issues a per-lesson share of the
covering payment's total; wired into all three cancel paths (student
self-cancel, instructor status update, admin student-detail cancel).
- PaymentService::applyCredits draws credit down FIFO across a run's charges,
marking a fully-covered charge paid-by-credit; the notice shows the credit
applied and reduced total, and the admin queue shows net due.
- Student detail page shows a student's credit balance and history.
Ships as part of the unreleased 1.2.0 (same release as scheduled billing).
Tests: composer test (585), composer lint, composer cs all pass.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Adds the #70 follow-up onto the student detail page: studio admins can now
cancel an upcoming lesson (same path as student cancellation — slot freed,
pending payment voided), withdraw an active group-class enrolment (seat
freed, pending payment voided), and edit the student's display name and
email with validation and uniqueness checks.
Action logic lives in the new Auth\StudentActions (unit-tested with mocked
repositories); the controller routes nonce-protected POSTs to it and shows
success/error notices.
Closes#70
Co-Authored-By: Claude Fable 5 <[email protected]>
The student-administration spec deferred three detail-view sections until
Payments landed. Adds them now: policy-acceptance history (title, version,
context, date), intake answers (label, answer, context), and — gated on
manage_billing — payment history with HST breakdown and receipt numbers.
New Auth\StudentHistory builds the display rows from per-student queries
added to AcceptanceRepository, AnswerRepository, and PaymentRepository;
the Payment model now carries created_at so unpaid rows still have a date.
Closes#69
Co-Authored-By: Claude Fable 5 <[email protected]>
Implements #22: a read-only Students area for studio admins.
- StudentController (manage_students): a list of us_student users with
upcoming-lesson and active-enrolment counts, each linking to a detail page
showing account info, upcoming/past lessons (offering, instructor, status),
and group-class enrolments.
- StudentSchedule::partition() — pure, unit-tested upcoming/past split.
- Repo counts: BookingRepository::countUpcomingForStudent and
EnrollmentRepository::countActiveForStudent (single-query, tested).
- Templates: templates/admin/students.php, student-detail.php.
- Students admin menu wired in AdminMenu (no Plugin change — the repos were
already available there).
- Docs: README status flipped to implemented; feature spec updated.
Payment history slots into the detail when Payments (#7) lands.
Tests: StudentScheduleTest + the two repo count tests. composer test (127),
cs, and PHPStan level 6 all pass.
Refs #22
Co-Authored-By: Claude Opus 4.8 <[email protected]>
- README.md: plugin overview, package-by-domain architecture, feature/status
table linking each docs/features spec (implemented vs planned), shortcodes,
REST namespace, roles, install via composer build, dev commands, and CI.
- docs/features/student-administration.md: spec for the planned studio-admin
Students list + per-student detail (upcoming/past lessons, group enrolments);
read-only; manage_students; no new tables. Tracked as #22.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
thatguygriffandClaude Opus 5