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]>

2026-07-18 18:17:20 -03:00

3.4 KiB

Raw Blame History

Feature: Student Administration

Overview

A read-only studio-admin area to browse students and drill into one student's history and upcoming activity — lessons and group-class enrolments — without digging through individual records.

Data Model

No new tables. The views are composed from existing data:

Students are WordPress users with the us_student role (get_users, get_userdata).
Lessons come from {prefix}us_lessons (with {prefix}us_availability for slot times).
Group-class enrolments come from {prefix}us_group_enrollments.
Policy acceptances come from {prefix}us_policy_acceptances (with the policy and version tables for titles/numbers).
Intake answers come from {prefix}us_question_answers (with {prefix}us_questions for labels).
Payments come from {prefix}us_payments.

Admin Interface

Students in wp-admin (manage_students, studio admin only):

List — every us_student user: display name, email, registered date, and quick counts (upcoming lessons, active group enrolments). Each row links to the detail view.
Detail (?student_id=):
- Account — display name, email, registered date.
- Upcoming lessons and Past lessons — split by the linked availability slot's start_dt; each shows date/time, offering, instructor, and status.
- Group-class enrolments — active/past, with offering title and status.
- Policy acceptances — every acceptance the student has recorded, newest first: policy title, version, context (account signup / lesson / enrolment), and when it was accepted.
- Intake answers — every registration-question answer, newest first: question label, answer, and the registration it was given for.
- Payment history (manage_billing only) — every payment, newest first: date, context, method, status, subtotal, HST, total, and receipt number.

Read-only in this iteration; cancel/edit actions are a possible follow-up (#70).

Capabilities

manage_students — studio admin (administrators inherit it via the user_has_cap filter). No new capabilities or tables.

Implementation

Admin controller: Unsupervised\Schedular\Auth\StudentController (list + detail)
Templates: templates/admin/students.php, templates/admin/student-detail.php
Reuses Booking\BookingRepository::findByStudent + countUpcomingForStudent, Availability\AvailabilityRepository::findById, Offering\OfferingRepository::findById, GroupClass\EnrollmentRepository::findByStudent + countActiveForStudent
History sections: Auth\StudentHistory builds the display rows from Policy\AcceptanceRepository::findByStudent, Registration\AnswerRepository::findByStudent, and Payment\PaymentRepository::findByStudent, resolving policy/version titles and question labels (unit-tested with mocked repositories).
Upcoming/past split: Auth\StudentSchedule::partition() (pure, unit-tested)
The upcoming/past split is extracted into a small pure helper so it is unit-testable (the controller itself follows the repo convention of not being unit-tested).

Tests

tests/Unit/Auth/StudentScheduleTest.php (the pure upcoming/past split helper)
tests/Unit/Auth/StudentHistoryTest.php (history display rows + fallbacks)
findByStudent coverage in tests/Unit/Policy/AcceptanceRepositoryTest.php, tests/Unit/Registration/AnswerRepositoryTest.php, and tests/Unit/Payment/PaymentRepositoryTest.php

3.4 KiB Raw Blame History