unsupervised-scheduler/docs/features/group-classes.md

Feature: Group Classes

Overview

Students enrol in a group class — an offering of kind group_class — as a commitment for the year. Enrolment is capacity-enforced and billed full-term upfront. Registration reuses the same flow as private lessons (intake questions + policy acceptance + payment).

A group class can be marked invite-only (us_offerings.access_mode = invite_only, see offerings.md). Invite-only classes are hidden from the public catalog — they never appear in the student booking/group-class list — and can only be enrolled in by students the instructor has let in. See Invite-only access below.

Data Model — {prefix}us_group_enrollments

Column	Type	Notes
id	BIGINT UNSIGNED	Primary key
offering_id	BIGINT UNSIGNED	FK → us_offerings.id (kind = group_class)
student_id	BIGINT UNSIGNED	WordPress user ID
instructor_id	BIGINT UNSIGNED	WordPress user ID (denormalised from the offering)
status	VARCHAR(20)	active / cancelled / completed
payment_id	BIGINT UNSIGNED	Nullable FK → us_payments.id
enrolled_by	BIGINT UNSIGNED	Staff member who added the student from wp-admin; 0 when the student (or their guardian) enrolled themselves
enrolled_at	DATETIME	Insertion time

Class Dates, Time, and Instructor

A group class offering carries term_start/term_end plus a class_time and an owning instructor_id (see offerings.md): one-off classes end the day they start; weekly classes run a set number of sessions, all at class_time. The class card on the enrolment page shows when the class meets (the date or date range plus the start time) and who teaches it (the assigned instructor's name, surfaced as instructor_name on the GET /offerings response). Instructor names in the group-class views (front and back end) use the instructor's real name (first + last) or nickname, never their login — see Auth\UserName::format().

Assigning an instructor to a scheduled class removes that instructor's open booking slots at the class time and flags any already-booked lesson that clashes; see Instructor assignment in offerings.md.

Sessions in the "upcoming" views

GroupClass\SessionSchedule turns an enrolment into the dated sessions behind it, so a class appears alongside one-to-one lessons wherever upcoming lessons are listed. A class is a term, not rows in us_availability, so an enrolment carries no date of its own — the concrete windows come from Offering::sessionWindows(), the same derivation the billing scan and the class-slot reconciler use, which is what keeps a student's list, an instructor's list and the invoice agreeing on when the class meets.

• upcomingForStudent() — every not-yet-started session of each enrolment that is not cancelled. completed is a billing state and says nothing about the calendar, so those sessions stay listed.
• upcomingForInstructor() — every session of each active group class they own, one row per session however many students are enrolled; enrolments are not consulted, because a class still has to be taught if nobody has signed up yet.

A class you are enrolled in must never silently vanish from these lists. Both the class time and the duration are optional on the offering form, and the schedule note exists precisely so a studio can write "Tuesdays 4:00pm" rather than pin the class to a clock. So the schedule degrades instead of disappearing:

Class has	What the list gets
date + time + duration	one dated row per remaining session, with an end time
date + time, no duration	one dated row per remaining session, end_dt empty — when it starts is worth showing without guessing when it ends
no class time	one row for the class as a whole, sorted by term start (or by "now" once the term is under way), with schedule text from Offering::scheduleLabel() — the studio's note, else the term dates, else "Schedule to be confirmed"
a term whose last day has passed	nothing

schedule is the tell: non-null means "a class, described in words, not a session at a known time", and every renderer shows that text in place of a date and time. An undated row's start_dt is a sort key only — never displayed.

Offering::sessionStarts() is the split that makes this work: it needs only the date and the time, because knowing when a class meets is a separate question from knowing how long it runs. sessionWindows() is that plus the duration, and still returns nothing without one — availability blocking and per-session billing need both ends of a window.

Consumers mark these rows kind = 'group_class' (SessionSchedule::KIND) and withhold the per-lesson actions from them: a session is one date in a term, not a booked slot, so there is nothing to cancel session by session and no slot to release. Withdrawing from the class is the separate, whole-enrolment decision.

Where they show up: the [us_scheduler] upcoming panel via GET /bookings (students and instructors both), and the Upcoming lessons table on the admin student detail page. Only upcoming sessions are added there — the Group-class enrolments table below already records the whole history, and a term's worth of past dates would bury the lessons under "Past lessons".

Enrolment Flow

The class list is loaded together with the household's enrolments (GET /enrollments), and the two are matched up per student, not per account. Each active enrolment in a class adds its own line to the card — "Ada is enrolled in this class." — with its own Withdraw button, and the Enrol button stays (reading "Enrol another student") for as long as anyone the account may enrol is still out of the class. The enrolment form then offers only those students; when exactly one is left the picker collapses to a hidden field carrying that student's id, because an omitted student_id reads as "enrol the account holder" and would sign up the parent instead of the last child. Only when the whole household is enrolled does the Enrol button disappear.

The per-student matching mirrors the server, which rejects a duplicate with 409 already_enrolled for that (offering, student) pair alone — a sibling is never a duplicate, and a cancelled enrolment does not block re-enrolling.

1. Student opens a group class from the offering catalog. Each class card shows its price with the cadence it is billed on — 120.00 CAD up front, 40.00 CAD monthly, and so on.
2. Student answers the offering's questions (GET /offerings/{id}/questions).
3. Student accepts the current published policy versions (GET /policies) — required to continue.
4. The enrolment form restates the price (with HST) and requires a second, separate agreement to pay that amount before it will submit. See Price Display and the Pay Agreement in payments.md.
5. Full-term payment is taken per the student's billing method (card by default; pending for e-transfer; skipped for comp). See payments.md.
6. POST /enrollments creates the enrolment (status = active), records answers and policy acceptances, and links the payment — but only if the offering's capacity has not been reached.
7. On successful payment (or comp) a receipt is emailed.

Capacity is enforced at enrolment time by counting active rows for the offering; a class at capacity rejects further enrolments.

Enrolment also closes after the class's enrolment deadline (the instructor's enrollment_deadline, defaulting to term_start — the first class day; see offerings.md). Past the deadline POST /enrollments rejects the enrolment with 403 enrollment_closed, and the class list shows "Enrolment has closed." in place of the Enrol button. While enrolment is still open the class card shows an "Enrol by" line with the effective deadline date.

The deadline only bounds student self-enrolment. An instructor (or studio admin) can still enrol someone by hand from the class details page — the Add students directly control, available for every group class, deliberately bypasses the deadline (and capacity) so a late enrolment can be added after the class has closed. Past the deadline the details page labels these as late enrolments. See Admin Interface below.

Withdrawal Flow

A student may withdraw themselves from a class they are enrolled in through the same group-class page: an active enrolment shows a Withdraw button. A guardian sees one per enrolled child, labelled with the child's name, so the right seat is the one released. POST /enrollments/{id}/withdraw marks the enrolment cancelled (freeing its capacity seat) and voids any still-pending payment. It never issues an account credit — a timely withdrawal is a clean exit, not a refund (credits are reserved for cancelled lessons; see credits.md).

Self-withdrawal is bounded by the class's withdrawal deadline (the instructor's withdrawal_deadline; see offerings.md). Unlike the enrolment deadline it has no implicit default — a class with no deadline set stays open to withdrawal for its whole life. Past the deadline POST /enrollments/{id}/withdraw rejects the request with 403 withdrawal_closed, and the class card shows "Withdrawal has closed — contact the studio to withdraw." in place of the Withdraw button. An enrolment that does not exist and one that is not the caller's own both return the same 404 not_found, deliberately: two different answers would let any signed-in student walk the id space and count the studio's enrolments, and there is nothing they could do with either answer. A withdrawal of an already-cancelled enrolment is idempotent. POST /bookings/{id}/cancel makes the same trade for the same reason.

The deadline only bounds student self-withdrawal. A studio admin can withdraw a student at any time from the student detail page (Auth\StudentActions::withdrawEnrollment), which is never subject to the deadline.

REST API

Method	Endpoint	Permission
GET	/wp-json/us-scheduler/v1/enrollments	Any logged-in user
POST	/wp-json/us-scheduler/v1/enrollments	book_lesson
POST	/wp-json/us-scheduler/v1/enrollments/{id}/withdraw	Owner (the enrolled student)

POST /enrollments body: offering_id, answers[] (question_id → value), accepted_policy_version_ids[], and payment data (see payments.md). The response includes id, status, and payment — a {id, method, status} summary, or null when the class is free (the front end then skips the payment step).

GET /enrollments returns the caller's own enrolments, or all enrolments for the instructor's group classes if the caller has view_own_lessons on those offerings.

GET /offerings (the catalog that feeds the group-class list) returns public offerings plus any invite-only offerings the caller has an access grant for, so a granted student sees the private class alongside public ones. Ungranted students never receive it. Enrolling in an invite-only class requires a grant: POST /enrollments rejects an ungranted student with 403 invite_required, and a successful enrolment flips their grant from invited to enrolled.

Invite-only access

Access to an invite-only class is recorded in {prefix}us_group_access — a grant per person, separate from the enrolment itself. The instructor manages access from My Lessons → My Group Classes. Add students directly is available on every class's details page (see Admin Interface); invite-only classes add two more controls beneath it:

1. Add students directly — the selected registered students are enrolled immediately (status = active) with a pending payment at the class price (comp students are settled at once by PaymentService). No access grant is needed — this writes straight to us_group_enrollments + us_payments. It bypasses the enrolment deadline and capacity, so it doubles as the late-enrolment path after a class has closed. The enrolment records who added them (enrolled_by), which is what later allows its intake to be recorded — see Recording Intake Collected Elsewhere.
2. Make available — the selected registered students get an invited grant so the class appears in their own group-class list; they then self-enrol through the normal paid flow. Each is emailed a "you've been added" notice.
3. Invite by email — for an address with no account yet: a tokenised personal invite (us_invites, carrying offering_id) is created and the registration link emailed, alongside an invited grant keyed by email + invite_id. If the address already has a pending invite, the grant is attached to that invite and no second link is sent. An address that already has an account is treated as Make available instead.

Both student-picking controls vet every posted id with Auth\RoleManager::isStudent() before acting on it — the same predicate the picker is built from, and the same one Booking\AdminBooking guards a staff booking with. A posted id naming an instructor, an administrator, or an account deleted since the page was drawn is skipped rather than enrolled, so nothing can put a non-student on a roster or raise a payment against one. Being a student is a matter of the role, not the book_lesson capability, so a guardian's child and a signup still awaiting approval are both fully enrollable — neither may enrol themselves, which is exactly what the studio adding them is for. The reported count is what was actually added, so a skipped id shows up as a smaller number.

When an email-invited person completes registration, RegistrationPage links their new account to the grant (GroupAccessRepository::linkStudentByEmail), so the invite-only class becomes enrollable for them — they choose whether to enrol.

Data Model — {prefix}us_group_access

Column	Type	Notes
id	BIGINT UNSIGNED	Primary key
offering_id	BIGINT UNSIGNED	FK → us_offerings.id (an invite-only group class)
student_id	BIGINT UNSIGNED	WordPress user ID; NULL until an email invitee registers
email	VARCHAR(191)	Email-invite grants only; used to link the account once it registers
invite_id	BIGINT UNSIGNED	FK → us_invites.id for email-invite grants; NULL otherwise
status	VARCHAR(20)	invited / enrolled / revoked
invited_by	BIGINT UNSIGNED	Instructor who granted access
created_at	DATETIME	Insertion time

Admin Interface

• Group Classes (view_all_lessons / studio admin): a per-class summary across instructors — each class with its instructor, when it meets, and its active-enrolment count against capacity (not a flat list of individual student enrolments). Selecting a class (?class_id=<id>) opens the same per-class details page described below, so a studio admin — including an owner-operator who also teaches, for whom the instructor My Group Classes menu is hidden — can view any class's roster and manage invite-only membership from here. Invite actions are permitted for the class's own instructor or any view_all_lessons studio admin.
• My Lessons → My Group Classes (view_own_lessons / instructor): a summary of the instructor's own group classes — each with when it meets and its active-enrolment count against capacity, plus a View details link (View & invite for invite-only classes). Selecting a class (?class_id=<id>, scoped to the owning instructor) opens its details page: a class-details panel (when, instructor, enrolled/capacity, duration, price, schedule note, enrolment deadline, status), the roster of enrolled students with enrolment and payment status, and an Add students section. Every class — public or invite-only — carries the Add students directly control there, which enrols the selected students immediately (a late enrolment past the deadline; the section says so when the deadline has passed). Invite-only classes additionally get the make-available and invite-by-email controls plus the list of who has been invited but not yet enrolled. These are nonce-checked usc_action POSTs, scoped to the owning instructor. The summary (templates/admin/my-group-classes.php) and the details page (templates/admin/my-group-class-detail.php) are separate templates.

Recording Intake Collected Elsewhere

A student the studio added with Add students directly has no intake answers and no policy acceptances: they were never shown the enrolment form. The answers are collected another way — a paper form at the first class, a phone call to a parent — and recorded afterwards from the enrolment detail page, reached from the Intake → View link on each roster row.

The page shows who and what the enrolment is, the audit trail of everything answered and agreed to so far, and — for a studio-made enrolment only — a Record intake collected elsewhere panel offering whatever is still missing. Every recording must say how it was collected (signed paper form / in person / over the phone / by email / some other way, the last requiring an explanation), and that is stamped on every row along with who entered it. Both audit tables carry a How it was given column, so a policy ticked online and one transcribed from paper never look alike.

Only a studio-made enrolment qualifies (Enrollment::isStaffRegistered(), i.e. enrolled_by > 0). An enrolment the student made already holds their own answers, and letting staff add to it would make the record editable after the event. Nothing already recorded can be overwritten: the submission is narrowed to what is genuinely still pending before anything is written, so a stale or double-posted form is harmless.

This is the same mechanism the Scheduler uses for lessons it booked, and the reasoning behind each rule — why no IP is stored, why accepted_by stays the student while recorded_by names the staff member — is set out once in Recording Intake Collected Elsewhere in lesson-booking.md. An enrolment is its own registration, so unlike a weekly lesson series there is no anchor to follow: one enrolment, one intake record, however many sessions the term holds.

Scoping matches the rest of the detail pages: an instructor may only open enrolments in their own classes, a view_all_lessons studio admin any.

Implementation

• Repository: Unsupervised\Schedular\GroupClass\EnrollmentRepository (countActiveForOffering/hasActiveEnrollment enforce capacity and prevent duplicates)
• Access grants: Unsupervised\Schedular\GroupClass\GroupAccess + GroupAccessRepository (hasGrant, findGrantedOfferingIds, markEnrolled, linkStudentByEmail)
• Model: Unsupervised\Schedular\GroupClass\Enrollment
• Sessions: Unsupervised\Schedular\GroupClass\SessionSchedule (upcomingForStudent, upcomingForInstructor) — consumed by Booking\BookingEndpoint::myLessons() and Auth\StudentController
• Admin controller: Unsupervised\Schedular\GroupClass\GroupClassController — renderPage (studio admin per-class summary, view_all_lessons) and renderInstructorPage (instructor summary + ?class_id roster detail, view_own_lessons). Both also route ?enrollment_id= to the enrolment detail view (maybeRenderEnrollmentDetail, template templates/admin/enrollment-detail.php)
• Intake audit + late recording: Unsupervised\Schedular\Registration\IntakeAudit and IntakeRecording, shared with lesson bookings. Enrollment implements Registration\IntakeSubject to take part
• REST endpoint: Unsupervised\Schedular\GroupClass\EnrollmentEndpoint
• Frontend: Unsupervised\Schedular\GroupClass\GroupClassPage ([us_group_classes] shortcode; offering="…" restricts it to a single class for embedding on a dedicated page — the block equivalent is the offeringId attribute). In single-class mode assets/js/group-classes.js leaves the class description out of the card, since the page it is embedded on already describes the class; the schedule, instructor, schedule note, price and enrolment controls are still shown.
• Reuses Registration\RegistrationGate (intake answers + booking-scoped policy acceptance, type enrollment)

Payment: a priced enrolment creates a payment via Payment\PaymentService (registration_type = enrollment) and links it as payment_id; unpriced enrolments return payment: null and skip the payment step. See payments.md for the card/e-transfer/comp flows.

Tests

• tests/Unit/GroupClass/GroupClassControllerTest.php (roster + add/make-available/invite actions)
• tests/Unit/GroupClass/EnrollmentTest.php
• tests/Unit/GroupClass/EnrollmentRepositoryTest.php
• tests/Unit/GroupClass/EnrollmentEndpointTest.php (invite-only gating)
• tests/Unit/GroupClass/GroupAccessTest.php
• tests/Unit/GroupClass/GroupAccessRepositoryTest.php
• tests/Unit/GroupClass/GroupClassPageTest.php
• tests/Unit/GroupClass/SessionScheduleTest.php
• tests/Unit/Offering/OfferingEndpointTest.php (catalog merges granted invite-only classes)

Enrolling A Child

POST /enrollments accepts the same optional student_id as booking, authorised through Guardian\GuardianService::canActFor(); GET /enrollments covers the guardian's whole household, and a guardian may withdraw any of their children. See parent-guardian-accounts.md.