Save the table-board draft

In this article

Before you start

• The operator is signed in with an active organisation and location, for example Harbor Demo Group and Harbor Soho.
• The occurrence detail is open at `/:orgId/:locationId/reservations/:occurrenceId`, using `BOOKING_TABLES_DETAIL_OCCURRENCE_ID` for GB documentation captures.
• The occurrence has reservations, existing table assignments and an active layout with tables loaded.
• The operator has `reservation:manage`; `reservation:view` can load the detail but cannot save board changes.
• The occurrence is not in `booking_mode=waiting_list`, because waiting-list mode does not expose board saving.
• At least one reservation has temporary table changes on the board, created by adding or removing tables in the timeline or by loading an optimisation solution as a draft.

Instructions

1. 1.

   Open the occurrence board

   Open the Harbor Soho service occurrence and switch to the table timeline board. In the current en-GB runtime, the tab may still appear as `Cronograma`.

2. 2.

   Create or review the draft

   Adjust the reservation's tables on the board, or review a draft loaded from an optimisation result. Use visible demo data such as Liam Scott only when that reservation is present in the documentation runtime.

3. 3.

   Check the pending footer

   When the board differs from saved assignments, Antylogic shows a pending-changes footer with the modified reservation count and actions such as `Revertir cambios` and `Save` or `Guardar`, depending on the active translation fallback.

4. 4.

   Save the draft

   Select the footer save action. The board saves each dirty reservation sequentially, sending one `PUT /api/app/{orgId}/{locationId}/reservations/{reservationId}/tables` request with the complete `table_ids` list for that reservation.

5. 5.

   Confirm manual mode if requested

   If automatic optimisation cannot confirm a viable distribution, the first save attempt is blocked with `error.optimization.manual_confirmation_required`. Confirm only when the operator accepts switching the occurrence to manual handling, then the app retries with `confirm_manual_mode: true`.

6. 6.

   Confirm the saved state

   After a successful save, the screen refreshes the occurrence, reservations and table assignments. The pending footer disappears when the saved assignments match the board draft.

7. 7.

   Resolve changes before leaving

   If the operator tries to leave or start another action with a draft still pending, use the confirmation dialog: apply changes to save first, choose `No aplicar` to discard, or cancel to keep working on the board.

Validations and limits

• Saving from the board requires `reservation:manage`; read-only users can view the board but cannot commit assignments.
• The app requires `orgId` and `locationId` to build the backend request.
• Each modified reservation is saved with a separate request; the board save is not a batch transaction.
• Saving replaces the complete table set for each modified reservation. It is not an incremental add-table or remove-table operation.
• An empty `table_ids` list removes all existing table assignments for that reservation.
• Waitlist reservations cannot receive non-empty `table_ids`.
• The write route accepts only `table_ids` and optional `confirm_manual_mode`; it does not let the client set `assignment_mode` or `source_run_id`.
• Saved board assignments are stored as `manual_fixed` without `source_run_id`.
• The UI filters table IDs against the loaded layout, and the backend also depends on valid `layout_tables`.
• If one reservation save fails, that reservation keeps its draft so the operator can review the error before continuing.

Expected result

The modified reservations keep their saved table assignments, the occurrence and assignment data are refreshed, optimisation state is invalidated as needed, and the board no longer shows a pending-draft footer when all saved assignments match the draft.