16 Commits

Include renames

Author	SHA1	Message	Date
thatguygriffandClaude Opus 5	b772e1811e	Let parents register once and book for their children ... 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]>	2026-07-29 16:07:52 -03:00
thatguygriffandClaude Opus 5	9344ab7193	Show price cadence and require a pay agreement at booking ... Every price a student meets on the front end now carries the cadence it is billed on — at booking, up front, weekly, monthly — so a bare amount can no longer read as a one-off when it is a recurring charge. Both registration forms then restate the price and require a second, separate tick agreeing to pay it, distinct from the policy acceptances above it. The agreed figure includes the studio HST so it matches Payment::total(), the amount actually billed; the rate reaches the browser as a new localized `taxRate`. A weekly reservation is charged per lesson for every week it claims, and a week another student takes first is simply not claimed, so its total is quoted as a ceiling ("up to 12 lessons") rather than a promise. Free offerings have nothing to agree to and show no price block at all. The formatting and the agreement live in one shared helper (`window.usPricing`, registered as `us-scheduler-pricing`) so a price reads the same in the booking form, the class catalogue and the editor preview. Closes #124 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-28 14:43:38 -03:00
thatguygriffandClaude Opus 5	c4acdb7ca4	Omit the class description when the group block shows one class ... The Group Classes block can be pinned to a single class via its Class option so it can be embedded on a page dedicated to that class. On such a page the surrounding copy already describes the class, so the card repeated it. In single-class mode the description is now left out and the card shows only the schedule, instructor, schedule note, price, enrolment deadline and the enrol/withdraw controls. The editor preview follows the same rule: BlockPreview::groupClasses() takes the mode from the block's offeringId attribute, drops the sample description when a class is pinned, and notes what the published page shows. Its sample card also gained the .us-class-when and .us-enrol-deadline elements the live markup has always rendered. Closes #114 Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-28 10:39:09 -03:00
thatguygriffandClaude Opus 4.8	2c4b481077	Add group-class withdrawal deadline and kind-aware offering form ... Group classes now carry an optional per-class withdrawal deadline. Up to that day a student may withdraw themselves from the class; the withdrawal frees the seat and voids any pending payment but never issues an account credit. After the deadline self-withdrawal closes and a studio admin must withdraw the student by hand (the admin path is never subject to the deadline). A blank deadline keeps self-withdrawal open indefinitely. Also make the Add/Edit Offering form show only the fields relevant to the selected kind: group settings for group classes, weekly reservation for private lessons. Progressive enhancement — without JS every field renders. - New nullable us_offerings.withdrawal_deadline column; Offering model gains $withdrawalDeadline + isWithdrawalOpen(). - New student endpoint POST /enrollments/{id}/withdraw, gated by the deadline (403 withdrawal_closed), ownership-checked, idempotent. - Front-end group-class page shows a Withdraw button while open. - No USC_VERSION bump: 1.2.0 is unreleased and accumulates schema changes under its section, matching the scheduled-billing and credit features. Tests: composer test (596), composer lint, composer cs all pass. Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-07-24 15:56:40 -03:00
thatguygriffandClaude Opus 4.8	fc7c0fa966	Show "Enrol by <date>" on the group-class card while enrolment is open ... The front end used the deadline only to gate the Enrol button; students had no way to see when enrolment closes. Add an "Enrol by <date>" line to each class card, shown while enrolment is still open, for the effective deadline (the instructor's date, or the first class day by default). Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-07-24 10:36:51 -03:00
thatguygriffandClaude Opus 4.8	bf29162587	Add group-class enrolment deadline with instructor late-enrolment override ... Group classes gain an instructor-set enrolment deadline (new us_offerings.enrollment_deadline column) that defaults to the first day of the class (term_start). Past the deadline students can no longer self-enrol: the enrolment endpoint rejects it (403 enrollment_closed) and the front-end class list shows "Enrolment has closed." in place of the Enrol button. Instructors keep a manual path: the "Add students directly" control on each class's details page now renders for public classes too (not just invite-only) and deliberately bypasses the deadline and capacity, so a student can be added as a late enrolment after the class has closed. Past the deadline the details page labels these as late enrolments. Bumps USC_VERSION to 1.1.3 for the schema change. Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-07-24 10:19:38 -03:00
thatguygriffandClaude Opus 4.8	87cfe921a9	Show instructor real name or nickname in group-class views, not the login ... Add Auth\UserName::format(), which prefers a user's first + last name, then their nickname, avoiding display_name (which can be the login/username). Route the instructor name through it in both the front-end offerings response (instructor_name) and the back-end group-class summary and details views. Tests: composer test (513), composer lint, composer cs all pass. Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-07-23 17:50:34 -03:00
thatguygriffandClaude Opus 4.8	b066bef353	Add group-class scheduling, instructor assignment, and details/invite management ... Group classes now carry a specific class time (alongside date and duration) and an assigned instructor: - Schema: add `class_time` (TIME) to `us_offerings`; `Offering` gains `normalizeTime`/`sessionWindows`. (Rides the pending 1.0.0->1.1.0 dbDelta upgrade, so no version bump.) - Offering form: class-time field, plus a studio-admin instructor picker (plain instructors always own their own classes). - `ClassSlotReconciler`: assigning an instructor clears their open booking slots overlapping each session and flags already-booked lessons that clash (a booked lesson is never deleted). Uses new `AvailabilityRepository::findOverlapping`. - Front end: `GET /offerings` exposes `instructor_name`; the enrolment page shows who teaches each class and when it meets. Back-office group-class views redesigned: - Instructor **My Group Classes** and studio-admin **Group Classes** are now per-class summaries with enrolment counts, not flat student lists. - Each links through (`?class_id=<id>`) to a per-class **details page** (schedule panel, roster with payment status, and — for invite-only classes — the add/make-available/invite-by-email controls). Invite-only membership is managed entirely from this page. - Invite actions are allowed for the class's owning instructor or any `view_all_lessons` studio admin, so an owner-operator (studio admin who also teaches) can reach every class's roster and invites from the Group Classes page. Tests: composer test (508), composer lint, composer cs all pass. Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-07-23 17:29:48 -03:00
thatguygriffandClaude Opus 4.8	a281935811	Add invite-only group classes ... Group classes can now be marked invite-only (us_offerings.access_mode). Invite-only classes are hidden from the public catalog and reachable only when the instructor lets someone in via one of three paths, managed from My Lessons -> My Group Classes: - Add students directly: enrols them now with a pending payment. - Make available: grants registered students access to self-enrol through the normal paid flow (multi-select, emailed a notice). - Invite by email: tokenised registration invite tied to the class for a non-account address; after they register the class becomes enrollable. Reuses an existing pending invite instead of sending a second link. New us_group_access table records grants; GET /offerings merges granted invite-only classes for the caller; enrolment requires a grant (403 invite_required) and flips it to enrolled on success. composer test (487), composer lint, composer cs all pass. Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-07-23 13:51:02 -03:00
thatguygriffandClaude Opus 4.8	5f9d5ffc4f	Add instructor group-class roster view under My Lessons ... Instructors can now see their own group classes under My Lessons → My Group Classes (view_own_lessons): each class shows its active enrolment count against capacity plus a roster of enrolled students with enrolment and payment status. GroupClassController gains renderInstructorPage(), backed by the existing per-instructor enrolment query and a newly injected PaymentRepository for payment status. Wired as a submenu under the existing My Lessons menu, inside the same !view_all_lessons guard so owner-operators don't get a duplicate item. Closes #71 Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-07-23 12:52:27 -03:00
thatguygriffandClaude Fable 5	da9a449d55	Update README and group-classes doc to reflect shipped Stripe payments ... The README still listed Payments as partial with the Stripe card charge pending, and group-classes.md still described the pre-#7 payment seam. Both are behind the code: StripeGateway/PaymentEndpoint ship the live card charge, and enrolments create and link payments via PaymentService. Fixes #73 Co-Authored-By: Claude Fable 5 <[email protected]>	2026-07-18 18:06:58 -03:00
thatguygriffandClaude Fable 5	30b0112431	Show enrolment status on the student group classes page ... The class list now loads the student's own enrolments alongside the catalog; a class they already have an active enrolment in shows "You are enrolled in this class." instead of the Enrol button, in both the browse-all catalog and the single-class embed mode. Previously the button always rendered and a duplicate attempt walked the student through the whole questions/policies flow before failing with 409 already_enrolled. A cancelled enrolment does not block re-enrolling, matching the server-side duplicate rule. Closes #61 Co-Authored-By: Claude Fable 5 <[email protected]>	2026-07-05 23:41:01 -03:00
thatguygriffandClaude Fable 5	cde8704267	Group class term dates, single-class embed mode, and offering editing ... Group class offerings now carry real dates: the add/edit form takes a start date plus a sessions control (one-off, or weekly for N sessions; the end date is computed as start + (N-1) weeks via Offering::weeklyTermEnd). Dates are validated strictly (Y-m-d) and shown in the offerings list and on the student-facing class card, including the weekly session count. [us_group_classes offering="<id>"] (block attribute offeringId, chosen from a dropdown of active classes fetched from the public offerings endpoint) restricts the page to a single class so the enrolment flow can be embedded on a page dedicated to that class; a pinned class that is no longer offered reports itself closed instead of falling back to the catalog. Offerings are now editable from the admin screen: an Edit button prefills the shared add/edit form and saving posts usc_action=update. Updates always preserve the original owner and currency, and non-admin instructors can only load and update their own offerings. The form also gains the previously missing description field and an Active toggle (the admin-UI counterpart of the REST is_active flag) so an edit cannot wipe data the form never collected. Closes #59 Co-Authored-By: Claude Fable 5 <[email protected]>	2026-07-05 23:18:59 -03:00
thatguygriffandClaude Fable 5	5888032ed7	Skip payment step for unpriced bookings, confirm them immediately, show students their lessons ... Booking a slot with no priced offering created the lesson but no payment, yet the front end still called POST /payments/intent, which 400ed with "Could not start payment for this registration" — the student saw an error while the backend held a claimed slot and a lesson stuck at pending. - POST /bookings and POST /enrollments now return a `payment` summary ({id, method, status}) or null when nothing is owed; the JS only runs the payment step when a payment exists. - Bookings with nothing owed are confirmed at creation — there is no payment step that would ever confirm them later. - The booking page now shows the student's upcoming lessons (GET /bookings, now scoped to upcoming non-cancelled lessons with slot start/end times) with a pending-payment/confirmed status badge. Fixes #53 Co-Authored-By: Claude Fable 5 <[email protected]>	2026-07-05 17:02:38 -03:00
thatguygriffandClaude Opus 4.8	9cb5207dcd	Add group-class enrolment (year commitment, capacity, registration gate) ... Implements #4: students enrol in a group_class offering via the same registration gate as private lessons (intake questions + booking-scoped policy acceptance). Enrolment is capacity-enforced and prevents duplicates. - Schema: us_group_enrollments table. - Enrollment value object + EnrollmentRepository (countActiveForOffering, hasActiveEnrollment, per-student/instructor/all-active queries, status). - EnrollmentEndpoint: GET /enrollments (scoped) and POST /enrollments (validates group_class, capacity, no-duplicate; reuses RegistrationGate; records answers/acceptances type enrollment). - GroupClassController + admin page (view_all_lessons): all active enrolments. - Front-end: [us_group_classes] shortcode (GroupClassPage) + group-classes.js enrol flow (list classes -> questions + policies -> POST /enrollments). - Wiring in Plugin, RestRegistrar, AdminMenu, ShortcodeRegistrar. Payment is the deferred seam (#7): enrolment lands active, payment_id null. JS left untested for parity with the repo's no-build vanilla-JS posture. Tests: tests/Unit/GroupClass/ (Enrollment, EnrollmentRepository). composer test (121), cs, and PHPStan level 6 all pass. Refs #4 Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-06-07 11:43:33 -03:00
thatguygriffandClaude Opus 4.8	d3a2767976	Add feature specs for booking platform requirements ... Update availability, lesson-booking, and user-roles docs and add specs for offerings, group classes, registration questions, versioned policies, Stripe payments (with e-transfer/comp overrides and receipts), and monthly per-instructor payment reporting. Tracked in issues #1-#9. Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-06-05 09:58:50 -03:00