A studio-admin area to browse students and drill into one student's history and upcoming activity. Read-only in this iteration.
Goal
Give the studio owner a single place to answer "who are my students and what's their activity?" without digging through individual lessons/enrolments.
Scope
Students list — admin page (Students, gated on manage_students): every us_student user with name, email, registered date, and quick counts (upcoming lessons, active group enrolments). Each row links to the detail view.
Student detail (?student_id=):
Account: display name, email, registered date.
Upcoming lessons and Past lessons — split by the linked availability slot's start_dt; show date/time, offering, instructor, status.
Group-class enrolments — active/past, with offering title and status.
(Later) policy-acceptance history, intake answers, and payment history once Payments (#7) lands.
Read-only for now (no cancel/edit actions); those can be a follow-up.
Capability
Reuses manage_students (studio admin; administrators inherit via the user_has_cap filter). No new caps or tables.
Data via existing pieces: get_users(['role' => us_student]) / get_userdata; Booking\BookingRepository::findByStudent; Availability\AvailabilityRepository::findById (slot times to split upcoming/past); Offering\OfferingRepository::findById (titles); GroupClass\EnrollmentRepository::findByStudent.
Wire into AdminMenu (a Students menu near Invites).
Extract the upcoming/past split into a small pure helper so it's unit-testable (controllers themselves remain untested per repo convention).
Dependencies
Builds on #3 (lessons, merged) and #4 (group enrolments, PR #21 — in review). Best implemented after #21 merges so the detail can include enrolments.
Slots before #7 Payments in the build order; payment history is added to the detail when #7 lands.
Acceptance
Studio admin sees a list of students and can open a detail page showing their upcoming + past lessons and group enrolments.
composer test, cs, PHPStan level 6 green.
A studio-admin area to browse students and drill into one student's history and upcoming activity. Read-only in this iteration.
## Goal
Give the studio owner a single place to answer "who are my students and what's their activity?" without digging through individual lessons/enrolments.
## Scope
- **Students list** — admin page (**Students**, gated on `manage_students`): every `us_student` user with name, email, registered date, and quick counts (upcoming lessons, active group enrolments). Each row links to the detail view.
- **Student detail** (`?student_id=`):
- **Account**: display name, email, registered date.
- **Upcoming lessons** and **Past lessons** — split by the linked availability slot's `start_dt`; show date/time, offering, instructor, status.
- **Group-class enrolments** — active/past, with offering title and status.
- (Later) policy-acceptance history, intake answers, and payment history once Payments (#7) lands.
- Read-only for now (no cancel/edit actions); those can be a follow-up.
## Capability
- Reuses `manage_students` (studio admin; administrators inherit via the `user_has_cap` filter). No new caps or tables.
## Implementation sketch
- `Auth\StudentController` (list + detail) + `templates/admin/students.php`, `templates/admin/student-detail.php`.
- Data via existing pieces: `get_users(['role' => us_student])` / `get_userdata`; `Booking\BookingRepository::findByStudent`; `Availability\AvailabilityRepository::findById` (slot times to split upcoming/past); `Offering\OfferingRepository::findById` (titles); `GroupClass\EnrollmentRepository::findByStudent`.
- Wire into `AdminMenu` (a **Students** menu near Invites).
- Extract the upcoming/past split into a small pure helper so it's unit-testable (controllers themselves remain untested per repo convention).
## Dependencies
- Builds on #3 (lessons, merged) and #4 (group enrolments, PR #21 — in review). Best implemented after #21 merges so the detail can include enrolments.
- Slots **before #7 Payments** in the build order; payment history is added to the detail when #7 lands.
## Acceptance
- Studio admin sees a list of students and can open a detail page showing their upcoming + past lessons and group enrolments.
- `composer test`, `cs`, PHPStan level 6 green.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
A studio-admin area to browse students and drill into one student's history and upcoming activity. Read-only in this iteration.
Goal
Give the studio owner a single place to answer "who are my students and what's their activity?" without digging through individual lessons/enrolments.
Scope
manage_students): everyus_studentuser with name, email, registered date, and quick counts (upcoming lessons, active group enrolments). Each row links to the detail view.?student_id=):start_dt; show date/time, offering, instructor, status.Capability
manage_students(studio admin; administrators inherit via theuser_has_capfilter). No new caps or tables.Implementation sketch
Auth\StudentController(list + detail) +templates/admin/students.php,templates/admin/student-detail.php.get_users(['role' => us_student])/get_userdata;Booking\BookingRepository::findByStudent;Availability\AvailabilityRepository::findById(slot times to split upcoming/past);Offering\OfferingRepository::findById(titles);GroupClass\EnrollmentRepository::findByStudent.AdminMenu(a Students menu near Invites).Dependencies
Acceptance
composer test,cs, PHPStan level 6 green.Closing as complete. Implemented and merged in PR #24 (read-only studio-admin Students view).