16 Commits

Include renames

Author	SHA1	Message	Date
Kydoimosandanthropic/claude-opus-4-8	a2c609803e	Add editable, previewable payment-due email template ... The "Payment due" notice the daily billing scan sends was fixed wording baked into PaymentDueMailer. Studio admins can now view, edit and preview its subject and body under Studio Settings -> Payment Due Email. - PaymentDueEmailTemplate stores subject/body/item-line as us_payment_due_email_* options, each falling back to the built-in default when blank, and renders via {token} substitution. - PaymentDueMailer now builds a token map from the same consolidated items/credit/e-transfer/reference data and renders the stored template; the default template reproduces the previous wording exactly. - PaymentEmailController serves the view/edit/save/reset admin page (manage_billing, nonce-checked) with a server-rendered sample preview. - PaymentEmailPreviewEndpoint (POST us-scheduler/v1/payment-email/preview, manage_billing) + payment-email-admin.js drive a live preview of unsaved edits. - Submenu wired under Studio Settings; endpoint wired in RestRegistrar. - Bump to 1.6.0 and add CHANGELOG entry. New options default gracefully, so existing sites need no migration and send the identical notice until edited. Co-authored-by: anthropic/claude-opus-4-8	2026-09-17 17:33:23 -03:00
Kydoimosandanthropic/claude-opus-4-8	acda3cda0f	Reconcile up-front charges when a class switches to monthly billing ... A student who enrols while a group class is pay-now is charged once at enrolment, and that charge carries no period_key. When the class is later switched to monthly, the daily scan — which dedups scheduled charges by period_key — does not see the up-front charge and bills the enrolment again for the current month, double-charging students who had already paid. The differing payer between the two rows (student vs guardian) was a side effect of guardian links created between the two charge dates, not the cause. Switching a group class into monthly now adopts each active enrolment's up-front charge into the current month (stamping period_key and due_date) so the scan treats that month as billed and charges from the next month on. Enrolments with no up-front charge, or already billed for the month, are left alone; weekly and non-group offerings are not touched. Wired into both offering-update paths (admin form and REST). Co-authored-by: anthropic/claude-opus-4-8	2026-09-17 15:07:22 -03:00
thatguygriffandClaude Opus 5	8c21a3fa9d	Let the studio book lessons and record intake collected elsewhere ... Two related gaps, closed together because the second is created by the first. A private lesson could only be booked by the student or their guardian, so a booking taken over the phone had no way in — where group classes have had "Add students directly" all along. "Book a lesson for a student" is now a panel on Scheduler and My Lessons: student, open time, lesson type, with weekly term reservations and a no-charge option for make-up lessons. The booking core is extracted to Booking\LessonBooker and shared with POST /bookings, so the two paths cannot drift on offering rules, slot claiming, or billing. That leaves a registration with no intake answers and no policy acceptances, because nobody was at a keyboard to give them — already true of every directly added group-class student. Ticking the boxes on a student's behalf would be an audit trail that says something untrue, so instead the answers are collected another way and recorded afterwards, from a lesson's or an enrolment's detail page. Every recording must say how it was collected, which is stamped on each row along with who typed it and shown in a new "How it was given" column: a policy ticked online and one transcribed from paper must never look alike. Only staff-made registrations qualify (us_lessons.booked_by, us_group_enrollments.enrolled_by) — one the student made already holds their own answers. Only what is still missing can be recorded, re-checked at write time, so a stale or double-posted form cannot duplicate or overwrite. No IP is stored for a transcription, and accepted_by stays the student while recorded_by names the staff member. Intake is now generic over Registration\IntakeSubject, which Lesson and Enrollment both implement; LessonDetail became Registration\IntakeAudit and is shared by both detail views rather than duplicated. Closes #182 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QfHt6CyJHz6KkA4RuaS7WK	2026-08-24 14:06:16 -03:00
thatguygriffandClaude Opus 5	cb347ffca0	Demo follow-ups: editable policy name, one-page signup, group classes in upcoming lessons, deletion cleanup ... Five items from the latest demo pass: - A policy's title can be edited from the Policies screen. Only the title moves; the slug is what the gates resolve policies by, so a rename can never detach a policy from acceptances already recorded against it. - Signup is one page again. The studio's registration questions move from a second step behind "Next" onto the main form, in an "About you" panel above the students being added, and that panel also asks an adult student for their birth year (the same us_birth_year meta a child's uses). register.js disables and hides the whole panel for a pure guardian, since the questions describe a student. - The password is re-scored on submit, not only as it is typed. zxcvbn's dictionary arrives after page load, so a password typed straight away was never scored at all and the first the student heard of it was the server rejecting the whole form. - Group-class sessions appear alongside lessons wherever upcoming lessons are listed: the [us_scheduler] panel (students and instructors) and the admin student detail page. GroupClass\SessionSchedule derives them from Offering::sessionWindows(), the same derivation the billing scan uses. They carry kind = 'group_class' and no Cancel action - a session is one date in a term, not a booked slot. - Deleting a user releases what the account was holding: each upcoming lesson is cancelled, its slot freed for rebooking, its pending payment voided, and active class enrolments cancelled. Past lessons and paid history are left alone. Tests: composer test (851), composer lint, composer cs all pass. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-30 11:45:04 -03:00
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
thatguygriff	171b655bb8	Stop the availability form failing in silence ... Adding availability for 5:30-6:00 PM with the lesson length left on its 60-minute default saved nothing and said nothing. A window is stored as consecutive lesson-length slots, so one that fits no lesson splits into none: splitByDuration() returned [], createFromWindow() inserted nothing, and addSlot() discarded the result and re-rendered the page unchanged. The REST endpoint already rejected that window with a 400. The admin form checked the same rules separately, and its copy was both laxer and mute — an unreadable date, an end before the start, and a two-day window were bare `return`s, and it never checked offering ownership at all, so a crafted POST could tie a slot to another instructor's offering and inherit their price and payment routing. Both callers now go through WindowValidator, which returns the window or a WP_Error explaining the refusal. The endpoint returns that error as is; the page renders its message as a notice. handleFormAction returns a [notice, error] pair so deletes report themselves too, and a successful add says how many slots it created. Two failures could also go unnoticed underneath: wpdb::insert's result was ignored, and insert_id still holds the previous statement's id after a failed write, so a failure looked like a success — and could become the recurrence group of a weekly series, orphaning every later occurrence. weeks was unbounded server-side despite the form's max=52. availability-admin.js narrows the lesson-length choices to those that fit the window and blocks submission when none do, which is what makes the original mistake hard to repeat. It is a convenience: the server validates regardless. Closes #130	2026-07-28 23:19:49 -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	8b90b8d78d	Add cancellation cutoff limiting how close to a lesson a student can cancel ... Students can no longer cancel their own lesson online once it starts within a configured window; instructors and studio admins can always cancel. - Studio default `us_cancellation_cutoff_hours` (stored/computed in hours, entered and displayed in days under Studio Settings → Cancellations). - Optional per-offering override `cancellation_cutoff_hours` (entered in hours); blank inherits the studio default, 0 allows anytime cancellation. - `Booking\CancellationPolicy` resolves the effective window and decides; `BookingEndpoint::cancel()` returns a 403 `cancellation_closed` when too late. The instructor status endpoint and studio-admin student actions bypass it. Closes #93 Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-07-23 11:57:18 -03:00
thatguygriffandClaude Opus 4.8	061d09e034	Harden booking, offering exposure, payments, and invites ... Security fixes from a pen-test review (issues #31–#37): - #31 Booking no longer trusts a client-supplied offering_id: a slot-tied offering is authoritative and any offering used must belong to the slot's instructor, closing a free/misrouted-payment bypass. - #34 Availability slot creation rejects an offering the instructor does not own (AvailabilityEndpoint now takes OfferingRepository). - #32 Offering/question/policy listing endpoints now require book_lesson instead of being public (no anonymous consumer exists); Offering::toArray also omits etransfer_email from listings as defense-in-depth. - #33 Slots are claimed atomically (UPDATE ... WHERE is_booked = 0) before a lesson is inserted, preventing a double-booking race. - #35 A single weekly booking is capped (MAX_WEEKLY_OCCURRENCES) and only creates lessons for slots it actually claimed. - #36 Stripe secret/webhook keys are write-only in the settings UI and a blank submit keeps the stored value; secrets are never echoed back into HTML. - #37 Pending invites expire after 14 days (Invite::isAcceptable), enforced at registration and surfaced on the admin invites list. Adds BookingEndpointTest plus Invite/Offering/AvailabilityRepository coverage and minimal WP_REST_Request/WP_REST_Response stubs. composer test (200), lint, and cs all green. Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-06-09 17:08:22 -03:00
thatguygriffandClaude Opus 4.8	6c4097b385	Add payments foundation (e-transfer/comp, Stripe config, receipts) ... Implements the payments foundation for #7. Without Stripe credentials everything works on e-transfer (pending payment confirmed by a studio admin); when Stripe keys are configured the default flips to credit card. Per-student override (card/etransfer/comp) is set on the student detail. - Schema: us_payments (amount DECIMAL dollars, method, status, receipt, stripe intent id). - src/Payment/: Payment VO, PaymentRepository, StudioSettings (Stripe options + isStripeConfigured + settings page), BillingMethodResolver (per-student override; default card if configured else etransfer), ReceiptMailer, PaymentService (create at registration, link payment_id, comp->paid+confirm, markPaid->confirm+receipt), PaymentController (e-transfer confirmation queue), PaymentEndpoint (PATCH /payments/{id}). - Booking + enrolment create the payment from the offering price; comp auto-confirms the lesson; setPaymentId on both repositories. - Admin: Studio Settings + Payments menus (manage_billing); per-student billing method on the student detail page. - Docs: payments.md + README updated. Deferred to a follow-up: the live Stripe card charge (PaymentIntent + Stripe.js Elements + webhook + stripe/stripe-php). Until then a card payment is created pending and confirmed like an e-transfer. Tests: tests/Unit/Payment/ (VO, repository, resolver, service, mailer). composer test (147), cs, and PHPStan level 6 all pass. Refs #7 Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-06-08 10:24:01 -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	6d163e5d0e	Add lesson booking registration flow (offering, questions, policies) ... Implements #3: students register for a private lesson by picking a slot, answering the offering's intake questions, and accepting booking-scoped policies. Payment is a clean seam for #7 (lessons land pending; payment_id null; instructor confirms via PATCH /bookings/{id}/status). - Schema: us_lessons += offering_id, recurrence, series_id, payment_id. - Lesson: new fields + recurrence constants. - BookingRepository::insertSeries() builds a weekly series sharing a series_id; AvailabilityRepository::findUnbookedInGroup() reserves a group. - RegistrationGate (src/Registration/): validate + record intake answers and booking-scoped policy acceptances. Reused by group enrolment (#4). - BookingEndpoint::book(): offering_id, recurrence, answers, accepted_policy_version_ids; single or weekly; records answers/acceptances (type lesson). - GET /policies?scope=booking filter. - Front-end booking.js: slot -> questions + policies -> submit. - Wiring: RegistrationGate built in Plugin, passed via RestRegistrar. - Test-only WP_Error stub in tests/bootstrap.php for gate testing. Refs #3 Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-06-07 11:25:30 -03:00
thatguygriffandClaude Opus 4.8	6225e772f8	Add Policies domain (drafting, versioning, tracked acceptance) ... Implements #6: studio admins draft, version, and publish policies; the public registration gate reads the current published version of each, and acceptance is recorded against the exact version so a new version must be re-accepted at the next booking. - src/Policy/: Policy, PolicyVersion, PolicyAcceptance value objects; PolicyRepository, PolicyVersionRepository, AcceptanceRepository; PolicyService (orchestrates create/add-draft/publish across the policies and versions tables); PolicyEndpoint (REST); PolicyController + templates/admin/policies.php (Policies admin menu, manage_policies) - us_policies, us_policy_versions, us_policy_acceptances tables in Schema - REST: public GET /policies (current published versions); manage_policies for create, add version, edit draft, and publish - Wiring in Plugin, RestRegistrar, AdminMenu AcceptanceRepository is built now and consumed by the booking/enrolment gate in #3/#4. Also bump PHPStan to --memory-limit=1G in the composer lint script; the default 128M now crashes the analysis as the codebase has grown. Tests: tests/Unit/Policy/ (value objects, repositories, service). composer test (90 total), cs, and PHPStan level 6 all pass. Refs #6 Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-06-05 15:00:54 -03:00
thatguygriffandClaude Opus 4.8	e61d99daed	Add Registration Questions domain (per-offering intake forms) ... Implements #5: studio admin / instructors author intake questions scoped per offering; answers are stored against a lesson or group enrolment via a polymorphic registration reference. - src/Registration/: Question + Answer value objects, QuestionRepository and AnswerRepository, QuestionEndpoint (REST), QuestionController + templates/admin/questions.php (Offerings -> Questions submenu) - us_questions and us_question_answers tables in Schema.php - REST: public GET /offerings/{id}/questions; POST/PATCH/DELETE /questions gated by manage_questions + offering ownership (owner or studio admin) - Field types text/textarea/select/checkbox; select options stored as JSON - Wiring in Plugin, RestRegistrar, AdminMenu AnswerRepository is built now and consumed by the booking/enrolment flow in #3/#4. Tests: tests/Unit/Registration/ (19 tests). composer test (63 total), cs, and PHPStan level 6 all pass. Refs #5 Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-06-05 11:11:06 -03:00
thatguygriffandClaude Opus 4.8	36331388d1	Add Offerings domain and studio-admin capabilities ... Implements the offerings catalog (#1): private-lesson types and group classes carrying pricing, billing mode (one_time/full_term), duration, capacity, and term details. Adds the src/Offering/ domain (value object, repository, REST endpoint, admin controller + template), the us_offerings table, and an Offerings admin page. Also lands the capability slice of #9: registers the us_studio_admin role and the new capability strings (manage_instructors, manage_offerings, manage_questions, manage_policies, manage_billing, view_all_payments, view_own_payments, export_payments) so offering management gates correctly. Tests: tests/Unit/Offering/ (value object + repository) and a studio-admin case in RoleManagerTest. composer test, cs, and PHPStan level 6 all pass. Refs #1 #9 Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-06-05 10:33:02 -03:00
thatguygriffandClaude Sonnet 4.6	2fb2ca392d	Restructure src/ and tests/ from package-by-type to package-by-domain ... All classes are now organised by domain (Availability, Booking, Auth). Each domain package contains its value object, repository, admin controller, REST endpoint, and any shortcode pages under a matching sub-namespace. Cross-cutting wiring (Plugin, AdminMenu, RestRegistrar, ShortcodeRegistrar, Schema) lives at src/ root. Tests mirror the domain structure. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>	2026-03-30 16:37:30 -03:00