Bug fix·2026.09.22·2026-09-23

Booking notification recovery

Staff-created bookings keep the notification channels selected for that action. “Don’t notify” stays silent when a confirmation is recovered later, and reviewed class restoration stays silent. Self-service confirmations keep their existing behavior.

# Booking notification recovery

Staff-created bookings keep the notification channels selected for that action. “Don’t notify” stays silent when a confirmation is recovered later, and reviewed class restoration stays silent. Self-service confirmations keep their existing behavior.

Merging client profiles keeps the original booking-notification decision in the retained history. It does not transfer permission to send a message to the merged account.

Delivery results distinguish sent, pending, held for review, failed and suppressed messages. A queued message is not described as sent. Booking webhooks, calendars, pass activation and accounting remain separate from optional client contact.

Attendance changes cancel stale notices that have not been claimed for delivery. A send already claimed is retained as potentially in flight; an uncertain outcome is not blindly sent again.

Admin API booking attempts require a stable Idempotency-Key. If the connection fails before the result is known, retry the exact request with that key. The saved booking is recovered without creating a second booking, repeating client notices or replacing notes changed since the original attempt.

Next update

Attendance history and report corrections

Staff reports now distinguish scheduled class-date attendance from action-date audit activity. Attendance History shows venue-local class dates, UTC and venue-local event timestamps, actors, status changes, credit effects, and separate check-in, Undo, and correction operation records. Older bookings with no recorded event say that history is unavailable instead of inventing a time. Tables and CSV

# Booking notification recovery Staff-created bookings keep the notification channels selected for that action. “Don’t notify” stays silent when a confirmation is recovered later, and reviewed class restoration stays silent. Self-service confirmations keep their existing behavior. Merging client profiles keeps the original booking-notification decision in the retained history. It does not transfer permission to send a message to the merged account. Delivery results distinguish sent, pending, held for review, failed and suppressed messages. A queued message is not described as sent. Booking webhooks, calendars, pass activation and accounting remain separate from optional client contact. Attendance changes cancel stale notices that have not been claimed for delivery. A send already claimed is retained as potentially in flight; an uncertain outcome is not blindly sent again. Admin API booking attempts require a stable Idempotency-Key. If the connection fails before the result is known, retry the exact request with that key. The saved booking is recovered without creating a second booking, repeating client notices or replacing notes changed since the original attempt.

All updates

Bug fix·2026.09.22·2026-09-23

Booking notification recovery

# Booking notification recovery

Staff-created bookings keep the notification channels selected for that action. “Don’t notify” stays silent when a confirmation is recovered later, and reviewed class restoration stays silent. Self-service confirmations keep their existing behavior.

Merging client profiles keeps the original booking-notification decision in the retained history. It does not transfer permission to send a message to the merged account.

Delivery results distinguish sent, pending, held for review, failed and suppressed messages. A queued message is not described as sent. Booking webhooks, calendars, pass activation and accounting remain separate from optional client contact.

Attendance changes cancel stale notices that have not been claimed for delivery. A send already claimed is retained as potentially in flight; an uncertain outcome is not blindly sent again.

Admin API booking attempts require a stable Idempotency-Key. If the connection fails before the result is known, retry the exact request with that key. The saved booking is recovered without creating a second booking, repeating client notices or replacing notes changed since the original attempt.

Next update