Youth age-up maintenance

age_up_members transitions eligible youth member accounts after they reach 18. It operates on personally identifying tenant data and must run inside one explicit tenant scope. The managed platform uses the allowlisted age-up-members schedule to fan out across active tenants.

Scheduling

The seeded schedule is due daily at 00:20 according to the platform schedule’s cron evaluation. The unified platform worker runs due schedules, records central job outcomes, and enters/restores each tenant connection before invoking the command.

bin/cake platform schedule run age-up-members

Suspended and archived tenants are excluded from this normal application maintenance. Do not loop database credentials in a shell script or run the command once against a process-global default connection for a hosted fleet.

Workflow-first behavior

A normal execution looks for an active member-age-up workflow definition in the current tenant. When present, it dispatches Members.AgeUpTriggered per Kingdom branch (or once without a kingdom if none exists). If the definition is absent or dispatch fails, the command reports the fallback and runs legacy logic.

Dry-run always uses legacy selection logic and does not start workflows.

Legacy eligibility and changes

Candidates must:

have one of the current minor member statuses;
have both birth_year and birth_month; and
have reached the eighteenth birth month as of FrozenDate::now().

The initial query includes earlier birth years and the target birth year up to the current month. Member::ageUpReview() then performs the entity-level transition, including mapping the prior minor status to Active or Verified Membership and removing the parent link when required. Changed members are saved in one transaction with system modified_by = 1.

The schema stores month/year rather than a full birthday, so the transition is month-granular. Do not infer or log a day of birth.

Dry run

bin/cake age_up_members --dry-run

Use this only when the CLI process is deliberately connected to the tenant being reviewed. It reports aggregate candidate/transition counts without persistence. Avoid adding member names, emails, birth values, or parent relationships to platform job messages or telemetry.

Monitoring and recovery

Check the age-up-members platform schedule, its per-tenant platform job/event records, scheduler logs, and tenant workflow logs. A failed save returns a non-zero result and the platform schedule records the target failure.

The operation is designed to be repeatable: already transitioned members no longer match the minor-status candidate set. If business rules were wrong, use a reviewed tenant-domain correction; do not edit central tenant metadata or replay another kingdom’s output.

Tests and change checklist

When member status or age policy changes, update and verify together:

Member::ageUpReview() and status constants;
AgeUpMembersCommand legacy candidate selection;
the active workflow definition/provider;
exact January/December, earlier-year, missing-month/year, and status cases;
dry-run and rollback behavior; and
sequential tenant A/B isolation.

Relevant sources:

app/src/Command/AgeUpMembersCommand.php
app/src/Model/Entity/Member.php
app/src/Services/WorkflowEngine/Providers/MembersWorkflowActions.php
app/src/Services/Platform/PlatformScheduleRunner.php