thatguygriffandClaude Opus 5
8c21a3fa9d
CI / Tests (PHP 8.1) (pull_request) Successful in 6m39s
CI / Tests (PHP 8.2) (pull_request) Successful in 57s
CI / Tests (PHP 8.3) (pull_request) Successful in 2m59s
CI / Tests (PHP 8.5) (pull_request) Successful in 3m31s
CI / No Debug Code (pull_request) Successful in 3s
CI / Coding Standards & Static Analysis (pull_request) Successful in 3m28s
CI / Build Plugin Zip (pull_request) Skipped
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
50 lines
1.9 KiB
PHP
50 lines
1.9 KiB
PHP
<?php
|
|
declare(strict_types=1);
|
|
|
|
namespace Unsupervised\Schedular\Registration;
|
|
|
|
/**
|
|
* A registration that intake answers and policy acceptances hang off: a booked
|
|
* lesson, or a group-class enrolment.
|
|
*
|
|
* The two are different enough to keep their own tables and their own booking
|
|
* flows, but identical in this one respect — somebody registered, questions were
|
|
* (or were not) answered, policies were (or were not) agreed to — and the rules
|
|
* for reading and recording that are not worth writing twice. Everything about
|
|
* intake works against this interface rather than either model.
|
|
*
|
|
* The `intake` prefix is not decoration: both implementations already carry
|
|
* `$studentId` and `$offeringId` properties, and PHP 8.1 has no way to declare a
|
|
* property on an interface, so the accessors need names of their own.
|
|
*/
|
|
interface IntakeSubject {
|
|
|
|
/**
|
|
* Which polymorphic registration table this is — `Answer::REG_LESSON` or
|
|
* `Answer::REG_ENROLLMENT`, matching the acceptance constants of the same
|
|
* names.
|
|
*/
|
|
public function intakeRegistrationType(): string;
|
|
|
|
/**
|
|
* The id answers and acceptances are stored against. Not always the row's own
|
|
* id: a weekly lesson series is answered for once, against its anchor, so
|
|
* every occurrence reads and writes the same registration.
|
|
*/
|
|
public function intakeRegistrationId(): int;
|
|
|
|
/** The offering whose questions apply. */
|
|
public function intakeOfferingId(): int;
|
|
|
|
/** Who the answers and acceptances belong to. */
|
|
public function intakeStudentId(): int;
|
|
|
|
/**
|
|
* Whether the studio registered this on the student's behalf, rather than the
|
|
* student (or their guardian) doing it themselves. Only these can have their
|
|
* intake recorded after the fact: one the student made already holds their own
|
|
* answers, and adding to those would make the record editable after the event.
|
|
*/
|
|
public function isStaffRegistered(): bool;
|
|
}
|