Unsupervised/unsupervised-scheduler
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Student administration view (studio-admin) #22

New Issue
Closed
opened 2026-06-07 15:04:01 +00:00 by thatguygriff · 1 comment
thatguygriff commented 2026-06-07 15:04:01 +00:00
Owner
Copy Link
Copy Source

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.
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.
thatguygriff added the feature label 2026-06-07 15:04:01 +00:00
thatguygriff commented 2026-06-08 19:05:28 +00:00
Author
Owner
Copy Link
Copy Source

Closing as complete. Implemented and merged in PR #24 (read-only studio-admin Students view).

Closing as complete. Implemented and merged in PR #24 (read-only studio-admin Students view).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something isn't working
 enhancement
Extends an existing feature
 feature
New user-facing capability
 payments
Billing, Stripe, receipts, reporting
 security
Security vulnerability or hardening
No Label feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
thatguygriff (James Griffin-Allwood)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Unsupervised/unsupervised-scheduler#22
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?