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]>
63 lines
2.2 KiB
PHP
63 lines
2.2 KiB
PHP
<?php
|
|
declare(strict_types=1);
|
|
|
|
namespace Unsupervised\Schedular\Guardian;
|
|
|
|
use Unsupervised\Schedular\Auth\RoleManager;
|
|
|
|
/**
|
|
* Keeps child accounts unusable as logins. A child holds the `us_student` role
|
|
* so every `student_id` lookup in the schema keeps working, but nobody is ever
|
|
* given its credentials — this closes the door the role would otherwise leave
|
|
* open:
|
|
*
|
|
* - authentication is refused outright, and
|
|
* - the booking capability is withheld, so nothing that reaches a capability
|
|
* check on a child's own session (there should be none) can book as them.
|
|
*
|
|
* Both key off the `us_child` meta, so ordinary students are untouched.
|
|
*/
|
|
class ChildLoginGate {
|
|
|
|
public function register(): void {
|
|
add_filter( 'wp_authenticate_user', [ $this, 'blockChildLogin' ], 10, 1 );
|
|
add_filter( 'user_has_cap', [ $this, 'withholdBooking' ], 10, 4 );
|
|
}
|
|
|
|
/**
|
|
* Refuse authentication for a child account. Runs after password
|
|
* verification, so it holds even if a password were somehow set on one.
|
|
*
|
|
* @param \WP_User|\WP_Error $user Authenticating user, or an earlier error.
|
|
* @return \WP_User|\WP_Error
|
|
*/
|
|
public function blockChildLogin( $user ) {
|
|
if ( $user instanceof \WP_User && GuardianService::isChild( (int) $user->ID ) ) {
|
|
return new \WP_Error(
|
|
'us_child_account',
|
|
esc_html__( 'This is a child account and cannot be signed in to. Please sign in with the parent or guardian account.', 'unsupervised-schedular' )
|
|
);
|
|
}
|
|
|
|
return $user;
|
|
}
|
|
|
|
/**
|
|
* Strip the booking capability from a child account, so the only route to a
|
|
* lesson in their name is their guardian's authorised booking.
|
|
*
|
|
* @param array<string, bool> $allcaps All capabilities currently held.
|
|
* @param array<int, string> $caps Required capabilities (unused).
|
|
* @param array<int, mixed> $args Callback args (unused).
|
|
* @param mixed $user The user being checked (a WP_User in practice).
|
|
* @return array<string, bool>
|
|
*/
|
|
public function withholdBooking( array $allcaps, array $caps, array $args, mixed $user ): array {
|
|
if ( $user instanceof \WP_User && GuardianService::isChild( (int) $user->ID ) ) {
|
|
unset( $allcaps[ RoleManager::CAP_BOOK_LESSON ] );
|
|
}
|
|
|
|
return $allcaps;
|
|
}
|
|
}
|