Bulk actions: acting on many bookings at once

When the thing that changed affects thirty bookings, not one, select them in the Bookings hub and use a bulk action. Every one routes through a confirmation screen first; there is no bulk button that acts on first click.

The actions

• Send an email: an ad-hoc message to the selected bookings' families. One email per unique address however many siblings are selected, and every send is logged.
• Move to a replacement session: bulk transfer for even or waived moves (anything money-moving goes through the single transfer screen, deliberately).
• Add internal note to all selected.
• Issue credit (bookings kept): goodwill credit while the bookings stand.
• Cancel and issue credit and Cancel without credit: the two endings, chosen explicitly.

The confirmation screen does the thinking

For financial actions the confirmation states the eligible count, the total value and the affected order numbers, requires a reason (audited), and lists every ineligible row with why it's skipped rather than silently including it:

• already cancelled or otherwise inactive;
• already compensated (credited or refunded); double compensation is structurally impossible;
• attendance already marked (the session happened; credit for a delivered class is a decision to take deliberately, one booking at a time);
• awaiting payment: credit is only ever issued for paid, confirmed bookings. Crediting an unpaid booking would mint credit for money never received, so both credit actions skip them.

Bulk moves run one transfer per booking: a full destination, duplicate student or price mismatch skips that row and reports it while the rest move, and the confirm screen pre-warns when the destination has fewer free places than you've selected rows.

Submitting the same batch twice processes nothing twice.

Deleting a booking record (administrators only)

Delete is the one action here that isn't a kind of cancellation: it removes the booking record itself, as if it had never been made. Nothing is credited, refunded or emailed, and there is no undo. It exists for records that should never have existed, a duplicate from a mis-click, a test booking; a family who changed their mind is a cancellation, not a deletion.

Because of that it's held to a higher bar. Only full site administrators see it, it runs through the same confirmation screen with an audited reason, and every deletion writes an audit row recording exactly what was removed, plus a note on the WooCommerce order, so the audit log remains the record of a booking that no longer exists. Active bookings and bookings still awaiting payment can't be deleted (deleting one with a live payment link would let a family pay for a booking that no longer exists); the confirm screen lists any such rows and skips them. The audit log, credit ledger and email log are never touched: history stays history.

When to reach for which

School's cancelling a session? Don't start here; cancel the session itself and let the outcomes panel drive per-student decisions and the properly previewed email. Bulk actions are for the cross-cutting cases: everyone in a class getting goodwill credit, a term's stragglers getting a nudge email, a venue change moving three sessions' worth of bookings to the replacement.