thatguygriffandClaude Opus 5
b772e1811e
A parent registers once and manages lessons for one or more children, who need no login of their own. A child is a real wp_users row with the student role but no usable login — so student_id keeps meaning "a WordPress user" on every table, and booking, credits, policies and enrolments work unchanged. A us_guardians link table maps guardian to child. The signup form gains a parent/guardian tick that reveals a block per child, with the account-signup questions asked per child rather than per guardian — they describe the student, not the account holder. Signup policies are recorded once per child with the guardian as the acceptor, which is the record that actually means something. A family that half-creates is rolled back entirely rather than leaving a guardian who cannot re-register. The booking and enrolment forms gain a "Who is this for?" picker listing children first, so the default selection is never the parent — booking for the wrong child is correctable, quietly billing a parent for their kid's lesson is not. POST /bookings and POST /enrollments take an optional student_id honoured only for that child's guardian; anything else is a 403. That check is the authorisation boundary of the feature. Payments and credits gain a payer: the charge names the child it was for and the guardian who owes it, so per-child reporting is unchanged while notices, receipts and the payment step reach the parent. Credit is held by the payer, so one child's cancellation can settle a sibling's charge, and the daily billing scan sends a guardian one notice covering every child. Closes #132 Co-Authored-By: Claude Opus 5 <[email protected]>
66 lines
2.0 KiB
PHP
66 lines
2.0 KiB
PHP
<?php
|
|
declare(strict_types=1);
|
|
|
|
namespace Unsupervised\Schedular;
|
|
|
|
use Unsupervised\Schedular\Auth\RoleManager;
|
|
use Unsupervised\Schedular\Availability\AvailabilityRepository;
|
|
use Unsupervised\Schedular\Payment\CreditRepository;
|
|
use Unsupervised\Schedular\Payment\PaymentRepository;
|
|
use Unsupervised\Schedular\Payment\ScheduledBillingRunner;
|
|
use Unsupervised\Schedular\Policy\AcceptanceRepository;
|
|
|
|
class Installer {
|
|
|
|
public function run(): void {
|
|
$this->createTables();
|
|
$this->migrateData();
|
|
( new RoleManager() )->createRoles();
|
|
$this->scheduleBilling();
|
|
flush_rewrite_rules();
|
|
update_option( 'us_schedular_version', USC_VERSION );
|
|
}
|
|
|
|
/**
|
|
* Ensure the daily scheduled-billing scan is registered with WP-Cron. Runs on
|
|
* activation and on every version-bump re-install, so an existing site that
|
|
* predates the feature picks the event up on its next deploy.
|
|
*/
|
|
private function scheduleBilling(): void {
|
|
if ( false === wp_next_scheduled( ScheduledBillingRunner::HOOK ) ) {
|
|
wp_schedule_event( time(), 'daily', ScheduledBillingRunner::HOOK );
|
|
}
|
|
}
|
|
|
|
private function createTables(): void {
|
|
global $wpdb;
|
|
if ( ! $wpdb instanceof \wpdb ) {
|
|
return;
|
|
}
|
|
$charset = $wpdb->get_charset_collate();
|
|
|
|
require_once ABSPATH . 'wp-admin/includes/upgrade.php';
|
|
|
|
foreach ( Schema::tables( $wpdb->prefix, $charset ) as $sql ) {
|
|
dbDelta( $sql );
|
|
}
|
|
}
|
|
|
|
private function migrateData(): void {
|
|
global $wpdb;
|
|
if ( ! $wpdb instanceof \wpdb ) {
|
|
return;
|
|
}
|
|
|
|
( new AvailabilityRepository( $wpdb ) )->splitOversizedWindows();
|
|
|
|
// Guardian accounts introduced "who pays" / "who agreed" alongside "who the
|
|
// student is". Every row written before then had them one and the same, so
|
|
// point the new columns at the student rather than leaving them 0 — the
|
|
// balance and acceptance lookups key on them directly.
|
|
( new PaymentRepository( $wpdb ) )->backfillPayerIds();
|
|
( new CreditRepository( $wpdb ) )->backfillPayerIds();
|
|
( new AcceptanceRepository( $wpdb ) )->backfillAcceptedBy();
|
|
}
|
|
}
|