9c900d6553
CI / Tests (PHP 8.1) (pull_request) Successful in 47s
CI / No Debug Code (pull_request) Successful in 2s
CI / Build Plugin Zip (pull_request) Has been skipped
CI / Coding Standards (pull_request) Successful in 52s
CI / PHPStan (pull_request) Successful in 1m1s
CI / Tests (PHP 8.2) (pull_request) Successful in 48s
CI / Tests (PHP 8.3) (pull_request) Successful in 45s
Implements #16: invite-only student self-registration through a front-end page, accepting signup-scoped policies at account creation. Policy domain: - us_policies.acceptance_scope (signup/booking/both); Policy::appliesTo(); PolicyRepository::findForScope(); scope threaded through PolicyService, the REST create, the admin controller, and the Policies form. - PolicyAcceptance::REG_ACCOUNT (registration_id = the new user's ID). Auth: - Invite value object + InviteRepository; us_invites table. - RegistrationController + Invites admin page (manage_students): invite an email, share the registration link, revoke. - RegistrationPage ([us_student_register] shortcode): validates the invite token, collects name/password, renders signup-scoped published policies with required acceptance, creates the us_student user, records account-type acceptances, marks the invite accepted, and logs the user in. - RoleManager: manage_students cap added to STUDIO_ADMIN_CAPS. Invite-only is implemented; the us_registration_mode self_approval path is a documented future seam. Docs: docs/features/account-registration.md; policies.md updated. Tests: tests/Unit/Auth/ (Invite, InviteRepository) plus Policy scope updates. composer test (104), cs, and PHPStan level 6 all pass. Refs #16 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
5.5 KiB
5.5 KiB
Feature: Policies
Overview
The studio admin drafts, versions, and publishes policies (e.g. cancellation, payment, code of conduct). Registrants must read and accept the current published version of every policy before they can book. Acceptance is recorded against the specific version, so when a policy is updated students must re-accept it at their next booking.
Data Model — {prefix}us_policies
| Column | Type | Notes |
|---|---|---|
id |
BIGINT UNSIGNED | Primary key |
title |
VARCHAR(191) | Display name |
slug |
VARCHAR(191) | Unique key, e.g. cancellation |
current_version_id |
BIGINT UNSIGNED | Nullable FK → us_policy_versions.id (published) |
acceptance_scope |
VARCHAR(20) | signup / booking / both — when it must be accepted |
created_at |
DATETIME | Insertion time |
Data Model — {prefix}us_policy_versions
| Column | Type | Notes |
|---|---|---|
id |
BIGINT UNSIGNED | Primary key |
policy_id |
BIGINT UNSIGNED | FK → us_policies.id |
version_number |
INT | Increments per policy, starting at 1 |
body |
LONGTEXT | The policy text (HTML/markdown) |
status |
VARCHAR(20) | draft / published / archived |
published_at |
DATETIME | When published; NULL for drafts |
created_at |
DATETIME | Insertion time |
Data Model — {prefix}us_policy_acceptances
| Column | Type | Notes |
|---|---|---|
id |
BIGINT UNSIGNED | Primary key |
policy_version_id |
BIGINT UNSIGNED | FK → us_policy_versions.id (the exact version accepted) |
student_id |
BIGINT UNSIGNED | WordPress user ID |
registration_type |
VARCHAR(20) | lesson or enrollment |
registration_id |
BIGINT UNSIGNED | FK → us_lessons.id or us_group_enrollments.id |
accepted_at |
DATETIME | Timestamp of acceptance |
ip_address |
VARCHAR(45) | IP captured at acceptance (audit trail) |
Versioning & Acceptance Rules
- Editing a published policy creates a new
draftversion; the old version stayspublisheduntil the draft is published. - Publishing a draft sets it
published, stampspublished_at, archives the prior version, and pointsus_policies.current_version_idat it. - The registration gate requires acceptance of the
current_version_idof every policy. Because acceptance is tied topolicy_version_id, a newly published version is unaccepted and must be re-accepted at the student's next booking.
Admin Interface
Policies in wp-admin (manage_policies, studio admin only):
- Create a policy; draft and edit version bodies
- Publish a draft version; view acceptance history per version
REST API
| Method | Endpoint | Permission |
|---|---|---|
GET |
/wp-json/us-scheduler/v1/policies |
Public (current published versions) |
POST |
/wp-json/us-scheduler/v1/policies |
manage_policies |
POST |
/wp-json/us-scheduler/v1/policies/{id}/versions |
manage_policies |
PATCH |
/wp-json/us-scheduler/v1/policies/{id}/versions/{vid} |
manage_policies |
POST |
/wp-json/us-scheduler/v1/policies/{id}/versions/{vid}/publish |
manage_policies |
Acceptances are not posted directly — they are written as part of POST /bookings
and POST /enrollments via the accepted_policy_version_ids[] field, which must
cover every policy's current version or the registration is rejected.
Implementation
- Repositories:
Unsupervised\Schedular\Policy\PolicyRepository,Unsupervised\Schedular\Policy\PolicyVersionRepository,Unsupervised\Schedular\Policy\AcceptanceRepository - Models:
Unsupervised\Schedular\Policy\Policy,Unsupervised\Schedular\Policy\PolicyVersion,Unsupervised\Schedular\Policy\PolicyAcceptance - Service:
Unsupervised\Schedular\Policy\PolicyService— orchestrates create / add-draft / publish across the policies and versions tables (archive prior current version, stamppublished_at, repointcurrent_version_id) - Admin controller:
Unsupervised\Schedular\Policy\PolicyController - REST endpoint:
Unsupervised\Schedular\Policy\PolicyEndpoint
Tests
tests/Unit/Policy/PolicyValueObjectsTest.phptests/Unit/Policy/PolicyRepositoryTest.phptests/Unit/Policy/PolicyVersionRepositoryTest.phptests/Unit/Policy/AcceptanceRepositoryTest.phptests/Unit/Policy/PolicyServiceTest.php