Replace reservation tables

In this article

Before you start

• The operator is signed in with Harbor Demo Group and Harbor Soho selected.
• The operator has `reservation:view` to open the occurrence and `reservation:manage` to save table changes.
• The reservation belongs to a service occurrence, such as Soho lunch service, and is visible on the Timeline tab.
• The occurrence has a loaded floor layout with visible `layout_tables`.
• For an automatic open occurrence, optimisation must validate the new table placement unless the operator confirms the switch to manual mode.

Instructions

1. 1.

   Open the occurrence timeline

   Open the Harbor Soho service occurrence and select the Timeline tab. Review the reservation rows, current table assignments and available layout tables before changing anything.

2. 2.

   Select the reservation

   Choose the reservation that needs a new allocation, for example Liam Scott. Do not assign tables to a waitlist reservation such as Sara Molina; waitlist reservations cannot be saved with non-empty `table_ids`.

3. 3.

   Set the final table list

   Add or remove tables until the reservation shows exactly the tables it should keep. Replacing Liam Scott with C4 and T1 means C4 and T1 become the complete saved allocation, not an addition to the old list.

4. 4.

   Review the draft bar

   After the table selection changes, the board keeps the new allocation as a temporary draft for that `reservationId`. Use Revert changes to discard it, or Save to persist it.

5. 5.

   Save the replacement

   Select Save. The app sends the reservation ID and final table list to `PUT /api/app/{orgId}/{locationId}/reservations/{reservationId}/tables`; the backend removes the previous assignment rows, writes the normalised list and returns the resulting assignments.

6. 6.

   Confirm manual mode if required

   If the occurrence is automatic and open, and optimisation rejects the new distribution, the app asks the operator to save and switch to manual mode. Confirm only when the manual placement should override automatic optimisation for this occurrence.

7. 7.

   Check the refreshed board

   After saving, the occurrence, reservations and assignments refresh. Confirm the reservation appears once on the board with the final table allocation and no stale preview solution remains visible.

Validations and limits

• This action replaces the complete table list for the reservation; it does not append tables incrementally.
• Saving an empty `table_ids` list clears all table assignments for that reservation.
• A waitlist reservation cannot be saved with assigned tables.
• Without `reservation:manage`, the board remains read-only and the backend blocks the `PUT` request.
• The request must contain valid JSON with `table_ids`; empty table IDs are ignored and duplicate IDs are collapsed before saving.
• Every saved table must exist in `layout_tables`.
• In the visual editor, when the table mode is not indifferent, at least one table must be selected before saving.
• If optimisation requires manual confirmation, the conflict response is `409` with code `6200`; confirming retries the same replacement with `confirm_manual_mode: true`.
• In `waiting_list` occurrence mode, the timeline does not expose the save handler, so reassignment is unavailable from the board.
• This route cannot change the customer, time, reservation status, restricted tables, preferred tables, `assignment_mode` or `source_run_id`.

Expected result

The Harbor Soho timeline refreshes with the persisted table allocation. Saved rows use `assignment_mode = manual_fixed`; if the occurrence had to switch to manual mode, the previous booking mode is stored and the optimisation state is reset.