Changelog

Member requests

• Membership, Classes and Check now look like progress steps instead of buttons.
• A compact counter stays visible while choosing classes. It shows places left,

explains when too many classes are selected and says how to continue.

• When an offered membership can accommodate all the selected classes, members

can switch to it without selecting their classes again. Availability, dates and household prices are checked again before sending.

• Unlimited memberships show no suggestion to downgrade when fewer classes are

selected. Instructions are shorter and repeated start-date text is removed.

Owner Telegram alerts

• An atomic household membership/class submission produces one owner Telegram

summary, including each member’s selected membership and number of classes.

• Matching owner Telegram automation steps share the same delivery reference.

Member-facing automations and their request-type conditions remain separate.

• Exact retries do not create another alert. Returning choices for changes and

submitting again creates a new occurrence. Existing queued historic alerts are not rewritten or replayed.

Operator rollout

Apply the new member-request-household-notifications preflight, editor and postflight SQL after the previously deployed household12+13 package, before merging/deploying this code. The correction replaces two existing functions; there are no new environment variables, feature flags, columns or grants. No production SQL or real Telegram delivery has been performed by this change.

Household memberships and costs

• Changing the club membership setup now opens a review. Staff can see shared

plans, pending changes and payment arrangements before saving. The server rechecks the review and protects against a second settings change.

• Existing memberships stay visible in Individual mode. Each household has a

route to ask members to choose new plans through the existing approval flow.

• Household costs now show member prices, discounts, caps and Video Review

add-ons, with current and planned totals separated by billing period. Incomplete prices are flagged instead of shown as a full bill.

• The household directory no longer labels basic plan-price sums as monthly bills.
• Request previews explain hidden membership options. Existing programme and

payment-type checks remain in place; saved requests keep their original options.

• Fixed-price Video Review add-ons are no longer grossed up a second time in

the member-request estimate when membership prices exclude VAT.

These household-review changes need no additional SQL, flags or environment settings. They use the existing household pricing, member-choice and add-on schema. The Telegram SQL rollout above is still a separate requirement from the preceding change. No live memberships, payments or messages are changed by this release preparation.

Household review follow-up

• Household costs refresh after saved plan or member changes. A changed plan

also resets the planned-price date so an old estimate is not left on screen.

• Paused plans stay visible with their pause end date, where one is recorded.

The date is a reminder to check the plan; it does not restart billing.

• Staff can replace one household's unanswered request with fresh choices.

Check the new request first. The old one closes only when its replacement is saved successfully. Replies and other households' requests are protected.

• Find households by name and switch between Needs checking, Reviewed and All.

Review progress is shared across staff and devices. Changed household details require another check.

This follow-up does require SQL before code: after the household Telegram SQL14 above, run the household-review-followup preflight, editor (units15/16), and postflight. It adds service-only review markers and an atomic replacement operation. No new flags, environment variables or cron schedules are required. The owner applies remote SQL; none has been applied by this work.

Smoother household reviews

• Prices and open requests stay visible during refresh. Unfinished request

edits stay open, with a clear message if a refresh fails.

• Saving a request updates the request lists without reloading household

details or recalculating prices. Insurance updates no longer reload prices.

• Marking a household reviewed checks just that household and its related

records. The initial review loads saved progress alongside membership data.

This performance correction needs no new SQL, flags or environment settings. The earlier household review units15/16 above still require their own rollout. Permissions, fresh server checks and payment behaviour are unchanged.

Development checks

• Behaviour changes now map important journeys, existing records, permissions,

interruptions and connected screens to repeatable checks. Late-found issues record the missing scenario and its prevention test.

• Household review and slow-refresh browser tests now run in local release

checks and CI, with receipts and screenshots for failures.

This development-process change requires no SQL or production settings. Browser fixtures do not replace real-login, database or provider verification.

CI quota fixture correction

• The Video Review concurrency test now uses its own synthetic student, so

earlier consumed quota cannot make it fail when test weeks overlap.

This corrects test setup only. Quota behaviour and deployed SQL are unchanged; the pending household SQL rollout above still applies.

Member portal

• What’s On shows your regular classes immediately while sessions, events and

competitions load. Missing information has a clear retry message; an incomplete day is not shown as empty.

• Choosing classes can begin while optional Video Review choices are loading.

Final confirmation waits for that check to finish.

• Request badges load a small count response instead of full request details.
• Confirming requests refreshes the household’s membership and classes as well as

its request list. Household and signed-in member cache boundaries stay separate.

• Home activity and attendance calculations run alongside independent reads.

The original home view loads only attendance totals; attendance read failures no longer appear as a successful empty history.

Staff pages

• Timetable loads its own settings without waiting for membership counts or fees.

Shared settings are reused between sections, with fresh reads after edits.

• Members and Dashboard prepare independent information in parallel while keeping

permission checks, sensitive-field filtering and complete-result checks.

Faster repeat visits and clearer feedback

• Progress keeps the latest selected grade when responses arrive out of order.

Reopening syllabus items shares one recent submission read; confirmed changes refresh it. The mobile journey is compact, with syllabus items before Video Review.

• Recent membership, grading, invoices, attendance and timeline reads are reused

briefly for the same staff user, club and member. Confirmed changes, sign-out and identity changes clear affected data; server authority is unchanged.

• Household refreshes retain current content and unsaved edits with an updating message. Calendar

navigation stays available while a new date range loads. Search has a clear loading state and retry, and loads its optional code on first use.

• AI drafts start immediately and show their result without decorative waits.

Changelog pages load a short archive window, with older updates still available.

• Audience preview checks up to four candidates at a time, retaining condition,

recipient, ordering and no-send behaviour. Progress reads run independently after ownership checks and report unavailable data instead of empty success.

• New development must assess performance together with security, including

read scope, freshness, failure handling and evidence of affected interactions.

Operator rollout

These changes require a code deployment only. No additional SQL, environment variables, flags or cron changes are introduced by this performance pass. The previous household-request package (12+13) remains a separate owner-applied prerequisite for that feature; use its existing preflight and postflight sequence. Live device timings and the owner’s cover-coach check remain post-deployment checks.

Startup and populated learning lists

• Browser startup shares one copy of the error-monitoring core. Early error

capture, navigation tracing and privacy filtering remain in place.

• Courses and pathways load independent reads together and fetch complete pages

of records, so larger lists do not silently lose courses or required tasks.

• Opening video feedback no longer prepares playback links for every clip.

Choosing a video still checks access and creates a fresh private link.

• This follow-up introduces no new SQL, flags or provider configuration. Physical

iPhone/PWA and live cover-coach verification remain deferred by the owner.

Household membership and class requests

• Families can choose and check each person's membership, classes and optional

Video Review, then submit the household's choices together. Separate request campaigns stay separate. If a choice cannot be saved, the whole submission is kept for correction rather than partly accepted.

• A confirmed household save stays successful if session renewal fails. When a

save result is uncertain, members are asked to refresh and check their choices.

• A running comparison shows the current monthly household cost and the cost with

the selected memberships. It includes family discounts, household caps and household members keeping their existing membership. Video Review is shown separately outside the membership cap; weekly and annual charges remain separate.

• Staff see a compact household approval list and open the household's changes in

a scrollable dialog. The next household is prefetched. Current choices are amber and submitted choices green, with date fields sized for phones.

Faster feedback

• Cover coaches can mark attendance without downloading the full register again

after every successful save. The confirmed mark and attendance count update in place. Saves remain guarded; failed or uncertain saves refresh the authority.

• Navigation shows when a page is opening and preloads destinations on pointer,

focus or touch intent. Normal navigation no longer remounts the main container or plays a page-entry animation on every change.

• Member Requests shows loading feedback and loads scheduled class changes without

delaying the household approval queue.

• Portal startup runs independent household, plan and insurance reads alongside

one another. Supporting read failures show a retry state instead of silently hiding plans, usage, ranks or club terminology.

• Staff pages wait for the initial sign-in check before mounting the workspace,

avoiding the duplicate header and page reads caused by mounting it twice.

Operator rollout

SQL first: after the already deployed speciality11 package, run the household preflight, additive household editor package (12+13), and matching postflight. Deploy through a green PR after that. No new environment variables, flags, cron schedules, provider operations or notification sends are required. Cover coach attendance improvements require the code deployment, with no additional SQL.

Portal and staff startup improvements need a code deployment only; they add no SQL.

Member requests

• Members choose a membership, eligible classes and any offered Video Review

add-on in one flow, then review and submit their choices together. Staff review covers the member's complete selection. Each family member remains independent.

• Keeping the current plan preserves its billing and allowance history while

allowing new regular classes to be selected.

• The optional age and grade restriction setting is preserved from the staff

preview through request creation and is checked again when choices are accepted.

Clear class and billing dates

• Requests show the class/allowance start separately from the new membership price

start. The selected timetable week is preserved when billing starts later.

• Existing supported monthly members retain their already-billed period. Approved

changes start on the class date, with the new price at the normal billing boundary. A narrowly verified transition prevents a second opening-period charge.

• Members without a plan receive an explicit first-charge date or a billing-review

explanation if that date cannot match the requested service start safely.

• Household/member summaries and email merge tags carry the separate dates.

Keeping a plan explicitly shows that membership and billing are unchanged.

Late responses

• A late class response can be completed within the same request. Existing valid

selections are retained and checked for eligibility, changed details and capacity.

• Staff can return choices for correction during review or before a scheduled

change has been applied. Saved answers remain visible and the member confirms again; applied or billed changes are protected from draft cleanup. A first-charge mismatch can be saved for billing review before any service or charge starts.

• Staff can choose a supported later date. For dated requests, new same-day changes use the next day

as the earliest safe start; previously accepted future changes keep their date. Past attendance and locked registers are preserved.

Unfinished membership and class choices

• Leaving the request page warns before discarding unfinished combined membership,

class and optional add-on choices, including standalone class requests.

• One page warning covers all household members. Saving one member does not clear

another member's unfinished choices. Failed or uncertain submissions stay protected.

• The form's Back/Next steps stay uninterrupted. Refresh and closing the tab use the

browser's native warning where supported. Force-closing a mobile app cannot be reliably intercepted; this does not add draft storage.

• This warning needs no additional SQL, environment variable or feature activation.

Operator rollout

• SQL first: use the final generated atomic member-choice package and its matching

source checksums/preflight/postflight after the existing add-on prerequisites. This correction is additive; applied historical source files are unchanged.

• New RPCs fail closed when unavailable. No new environment key or cron schedule is

required. Feature activation, live SQL and real notification/provider tests remain owner-controlled.

• New service_start_date and billing_start_date email tags are available. Starter

copy directs members to confirmed dates in the portal; installed/custom templates are preserved. effective_date continues to resolve to the actual service date where known. See the dated changeover operations record for final verification evidence and deployment order.

CI reliability

• The isolated billing-cycle test installs the current reviewed member-choice and

add-on SQL before exercising invoice generation, collection and settlement.

• Secret scanning recognises twelve reviewed database-constraint fingerprints in

one verification file. Other values and other files remain subject to scanning.

• These CI corrections add no production SQL, environment settings or activation.

Membership requests with external billing

• Members whose existing monthly membership is billed outside AllSorted can

select a replacement membership and regular classes without entering a billing date. The request keeps its configured approval process.

• The portal and staff review show Handled outside AllSorted. Approved

membership and class changes preserve automatic membership billing being off.

• Rollout is code first, followed by the new atomic external-billing forward SQL

package and its preflight/postflight. No billing-date backfill, new key or feature activation is needed. See the dated external-billing operations record.

Regular class choices

• Bookable sessions are excluded from regular class choices in member requests,

matching enrollment. Individual session booking remains available.

• Options run Monday to Sunday, then by start time. Saved requests recheck session

settings during submission, approval and scheduled application.

• This correction can be applied with SQL alone, after external-billing09, using

the regular-lessons10 atomic editor and its matching preflight/postflight. No class flags, existing rosters, payments or notifications are changed by the SQL.

Membership speciality lessons and portal weeks

• Memberships can include speciality lessons with an explicit Yes/No setting.

They count towards the usual regular-class allowance; bookable sessions stay separate. The setting defaults No and is checked in enrollment and member requests.

• Desktop members can switch class choices between Week and List without losing

their answers. Phones retain a stacked list.

• What's On adds a weekly timetable at the bottom, with household regular classes,

member-specific sessions/events and the existing booking details.

• Apply the separate speciality-lessons11 atomic SQL package before this code,

after regular-lessons10. No keys, new scheduled jobs or automatic plan activation. See the dated portal weekly/speciality operations record for verification and rollout.

Clearer member request wording

• Member requests show membership prices and start dates without references to

external billing systems or internal invoicing processes. Staff review retains the operational billing details. Member confirmations and review buttons use plain wording. Payment amounts, dates and request behaviour are unchanged.

• This wording update needs no additional SQL or configuration.

Mobile member requests

• Emergency-contact and medical-information editing uses clear, bordered buttons.

Long names, email addresses, medical text and class options wrap within the request cards on small phones, including while editing.

• Existing household confirmations and club review settings continue to apply.

Timetable changes

• Filter classes by All, Active, Scheduled, Ending soon or

Expired, alongside day, type, venue and programme. Ending soon means a currently running class ending within the next 30 days. It remains Active through its final date. Expired classes remain separate from archived ones.

• The status picker fits on phones; wider screens group filters side by side.

Class rows show their start/end dates. Exports use the selected filters.

• Add and edit class pages share four visible sections: class details, schedule,

who can attend, and places/booking. A summary, clearer switches, contextual trial/booking fields and a persistent save bar help with setup. Capacity is entered once. Existing class-plan editing and stale-save protection remain.

Members page background requests

• Member rows load their profile when opened, avoiding automatic route

prefetches for every visible row.

• The static app manifest and its bundled icons can be fetched without a staff session, preventing

browsers receiving a sign-in page where they expect manifest JSON. Protected staff pages and APIs keep their existing authentication checks.

• No new SQL, environment settings or feature flags are required for these Members page changes.

Membership plan filters

• Membership plans now have All, Active, Scheduled, Ending soon and Expired

filters, using the same inclusive dates and 30-day window as the timetable. Ending soon and Expired only appear when a non-archived plan matches.

• Date-aware badges and start/end dates explain each plan's availability on

desktop and mobile. If the last matching plan is removed or updated, its conditional filter disappears and the list returns to All.

• This is a display change only: existing agreements, prices, billing and

archived-plan controls are unchanged. No SQL or configuration is required.

Filtered member count

• The Members header now shows only the number matching the current filters,

such as 125 members, without the total including hidden leavers. Search, status and other filters continue to determine that count. An incomplete directory load still displays its warning alongside the filtered loaded count.

• Display-only change; no SQL or configuration required.

Optional monthly Video Review

• Clubs can offer Video Review as a monthly extra per member, allow members to

subscribe in the portal, or assign paid or complimentary access from a member's billing panel. Complimentary access can have an end date.

• Add-ons sit outside membership family discounts and household caps. A £100

capped membership bill plus two £10 add-ons totals £120. Membership-included Video Review does not need another paid add-on.

• Membership requests include a separate choice for each covered member and

retain the club's approval/effective-date rules. Clubs can also show an optional, unchecked choice during enrolment; it is separate from the joining payment.

• Paid access starts after confirmed payment and covers the actual paid period.

Cancellation stops future renewals while preserving that paid period. Existing independent grants retain their allowances.

• Operator rollout: apply add-on core01, billing02, requests03, enrollment04 and

quota05 before code deployment, after the dependencies in the add-on operations record. New offers are off by default. No new environment keys or cron schedule are required. Remote SQL and real payment-provider verification remain pending.

Household directory search

• Household search runs when Enter is pressed or after three seconds without

typing. Filters and later pages use the submitted search, and a new search begins at the first page. Assignment pickers keep their existing timing.

• No SQL, environment settings or feature flags are required.

Consistent membership information

• Household member rows, member membership details and the portal now use the

member's current agreement coverage. A previous enrolment selection no longer replaces an active agreement merely because the club changes billing model.

• Multiple programmes remain visible. Future memberships show their start date,

and scheduled changes stay separate until applied. Staff can see when a previous selection differs and open the household to review the existing agreements.

• Billing-model settings explain that changing the setting does not convert or

cancel existing memberships or payments. A failed save keeps the saved setting.

• Per-member selections show the chosen plan and start date separately. If the

change needs club review, the current agreement stays visible and the pending choice explains that it has not taken effect.

• No account conversion, invoice changes or payment-provider calls occur during

these reads. The pending-selection display requires the complete member-request membership correction SQL package before code. Existing mismatched records need separate review.

Membership and class requests for each member

• A membership/class request creates a separate named choice for every selected

member, including members who have no current membership. Siblings sharing a billing agreement choose their own membership, classes and optional Video Review.

• Approved future changes reserve places and wait until the compatible billing

date. Current coverage stays in place until then. The move changes only that member and reuses a compatible agreement when appropriate.

• Staff review, rejection, cancellation and household moves handle the pending

choices. Changed prices or membership circumstances require review; affected billing waits instead of charging an outdated selection. Cancelled future requests remove their own unbilled add-ons; approval retries keep the agreed start date. Existing subscriptions and recorded charges are preserved. Older household requests skip overlapping member choices, and expiry requests retry later.

• Billing uses a complete household snapshot after a member moves. Membership

caps still apply to memberships, while optional add-ons remain outside the cap.

• Operator rollout: apply the atomic member-request membership correction SQL

package after the Video Review add-on prerequisites and before this app. Run its preflight and postflight and retain all four final authorities together. No new keys, flags, pricing policies or cron schedules are required. This does not migrate a club's existing agreements just by changing billing model.