thatguygriff
6c4097b385
Implements the payments foundation for #7. Without Stripe credentials everything works on e-transfer (pending payment confirmed by a studio admin); when Stripe keys are configured the default flips to credit card. Per-student override (card/etransfer/comp) is set on the student detail. - Schema: us_payments (amount DECIMAL dollars, method, status, receipt, stripe intent id). - src/Payment/: Payment VO, PaymentRepository, StudioSettings (Stripe options + isStripeConfigured + settings page), BillingMethodResolver (per-student override; default card if configured else etransfer), ReceiptMailer, PaymentService (create at registration, link payment_id, comp->paid+confirm, markPaid->confirm+receipt), PaymentController (e-transfer confirmation queue), PaymentEndpoint (PATCH /payments/{id}). - Booking + enrolment create the payment from the offering price; comp auto-confirms the lesson; setPaymentId on both repositories. - Admin: Studio Settings + Payments menus (manage_billing); per-student billing method on the student detail page. - Docs: payments.md + README updated. Deferred to a follow-up: the live Stripe card charge (PaymentIntent + Stripe.js Elements + webhook + stripe/stripe-php). Until then a card payment is created pending and confirmed like an e-transfer. Tests: tests/Unit/Payment/ (VO, repository, resolver, service, mailer). composer test (147), cs, and PHPStan level 6 all pass. Refs #7 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Unsupervised Scheduler
A WordPress plugin for instructor/student lesson scheduling — private lessons and group classes — with offerings, intake questions, versioned policies, account registration, and (coming) online payments.
Version: 1.0.0-rc.1 · Requires: WordPress 6.0+, PHP 8.1+ · License: GPL-2.0-or-later
Pre-release. The booking platform is being built feature-by-feature; see Implementation status below.
Overview
The plugin is organised package-by-domain under src/ (PSR-4
Unsupervised\Schedular\). Each domain owns its value objects, repositories,
REST endpoints, and admin/front-end controllers. All data access goes through
repository classes against custom {prefix}us_* tables; permissions are enforced
with WordPress capabilities, never role-name checks. There is no front-end
build step (vanilla JS/CSS in assets/).
Every feature has a spec in docs/features/ describing its data
model, REST API, classes, and tests. For contributor/architecture guidance see
CLAUDE.md.
Implementation status
| Feature | Spec | Status |
|---|---|---|
| User roles & capabilities (studio admin / instructor / student) | user-roles.md | ✅ Implemented |
| Offerings (private-lesson types & group classes) | offerings.md | ✅ Implemented |
| Availability (durations, weekly recurrence, calendar) | availability-management.md | ✅ Implemented |
| Registration questions (per-offering intake) | registration-questions.md | ✅ Implemented |
| Policies (drafting, versioning, tracked acceptance) | policies.md | ✅ Implemented |
| Account registration (invite-only, signup policy acceptance) | account-registration.md | ✅ Implemented |
| Lesson booking (offering → questions → policies) | lesson-booking.md | ✅ Implemented |
| Group classes (capacity-enforced enrolment) | group-classes.md | ✅ Implemented |
| Student administration (studio-admin view) | student-administration.md | ✅ Implemented |
| Payments (e-transfer/comp + receipts; Stripe card charge pending) | payments.md | 🟡 Partial |
| Payment reporting (monthly per-instructor + CSV) | payment-reporting.md | 🟡 Planned |
Payments are deliberately deferred to the end: booking and enrolment ship with a clean seam (a lesson lands
pending, an enrolmentactive, withpayment_idnull) into which the pay→confirm + receipt step plugs later.
Shortcodes
| Shortcode | Purpose |
|---|---|
[us_booking] |
Student calendar + private-lesson registration flow |
[us_group_classes] |
Browse and enrol in group classes |
[us_student_login] |
Front-end student login |
[us_student_register] |
Invite-based account registration (accepts signup policies) |
REST API
All endpoints live under /wp-json/us-scheduler/v1/ (e.g. /offerings,
/availability, /bookings, /enrollments, /policies, /questions).
Permissions are enforced via permission_callback capability checks. See each
feature doc for the routes and required capabilities.
Roles & capabilities
Three custom roles — Studio Admin (us_studio_admin), Instructor
(us_instructor), and Student (us_student) — plus a user_has_cap filter
that grants every studio-admin capability to WordPress administrators, so the site
owner runs the studio without a separate role. Full capability matrix in
user-roles.md.
Installation
- Build a distributable zip (see Development):
composer build # -> dist/unsupervised-schedular-<version>.zip - In wp-admin: Plugins → Add New → Upload Plugin, choose the zip, install, and activate.
Activation creates the us_* database tables and registers the roles. CI also
publishes an installable zip artifact on every merge to main.
Development
composer install # install dependencies
composer test # PHPUnit (run after every change)
composer lint # PHPStan (level 6)
composer cs # PHPCS (WordPress coding standards)
composer cs:fix # auto-fix coding standards
composer build # build the plugin zip into dist/
# a single test file / single test
./vendor/bin/phpunit tests/Unit/Offering/OfferingRepositoryTest.php
./vendor/bin/phpunit --filter testInsertReturnsId
Tests use Brain\Monkey and Mockery to
stub WordPress and $wpdb without a full WP install. To run the plugin in a real
WordPress without Docker, wp-now works well: npx @wp-now/cli@latest start.
CI
Gitea Actions (.gitea/workflows/ci.yml) runs on every push and pull request:
lint (PHPCS), static-analysis (PHPStan), test (PHPUnit on PHP
8.1/8.2/8.3), and no-debug (rejects debug statements in src/). On merge to
main a build job publishes the installable plugin zip as an artifact.
License
GPL-2.0-or-later.