fix(bookings): update the bookings linked to an event in place (PPT-2813)

[camreeves]

What

createBookingsForEvent (shared by visitor, catering-order and asset bookings) deleted every booking linked to an event and recreated them on each save. It now:

• patches the existing booking for each resource still on the event (date, duration, title, host, asset, zones, attendees, details), and only when something differs
• creates bookings only for resources new to the event
• removes only the bookings whose resource was taken off the event
• still recreates a resource flagged _changed (catering orders and asset requests), so its approval starts again as before
• fetches linked bookings that sit outside the event's current period by id, so a moved event finds its old bookings instead of leaving them behind

Why

Booking ids changed on every edit, so the visitor mailer saw a delete and a create rather than a change: with the event path off attendees were re-invited on every edit and never told what changed, the QR code in the invitation stopped matching the booking, and a check-in was lost by any later edit. Three API calls per attendee per save became one or none. Full history and consequences are on PPT-2813.

Testing

• nx test bookings: 37 files pass. Four new cases in booking.fn.spec.ts cover patch in place, no request when nothing changed, removal of a dropped attendee, and a moved event finding its bookings by id.
• Not yet exercised on an environment. Suggested check on HIO UAT (or placeos-dev): book a room with an external attendee, edit the time, and confirm the attendee gets one "details changed" email and no new invitation, that the booking id in Concierge is unchanged, and that a checked-in visitor stays checked in after an edit.

Notes for review

• The patch does not send approved, rejected or checked_in, so a normal user's edit keeps whatever state the booking had. Before, an unchanged resource carried over approved and rejected on the recreated booking, so the outcome is the same; the _changed path is untouched.
• Patched bookings are not rolled back if a later create fails; only the bookings created in that call are removed, as before.

PPT-2813

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
frontend-templates	Ignored	Preview	Sep 25, 2026 12:27pm UTC

[camreeves]

Tested on HIO UAT with this branch served at /workplace-2813/ (build/feat/PPT-2813-linked-bookings/workplace, served main.js matches the branch build).

Create: Book Room in Ord Street with one external attendee. Requests were POST /events, then one POST /bookings for the attendee (booking 70186). The attendee received one invitation.

Edit: moved the start time by 30 minutes. Requests were PATCH /events/:id, GET /bookings?type=visitor for the new period (empty, the event moved), GET /bookings/70186 by id from linked_bookings, then PATCH /bookings/70186. No DELETE and no POST, so the booking id survived the edit. The attendee received one "Your meeting details have changed" email and no second invitation.

Not covered yet: catering-order and asset bookings on an edit, and the check-in survival case.

[camreeves]

Second UAT run with a catering order on the event (Sun 27 Sep, G-04). Create: POST /events, then one POST /bookings for the visitor and one for the catering order. Edit (start moved 30 minutes): PATCH /events, then GET and PATCH of the visitor booking in place, but no request at all for the catering order. The catering sync is guarded in event-form.service.ts by this._model().catering?.length, and on edit the model had no catering, so the sync never ran. That guard is not changed by this PR, so the old code would have skipped it too, but it leaves the catering order's time unverified after an edit. To check before merging: whether the edit form loads existing catering orders into the model, the order's time in Concierge after the edit, and whether staff-api moves event-linked bookings on an event PATCH. Assets were not exercised (no asset could be attached to the Ord Street zone on UAT).