Change Reservation Acceptance

In this article

Before you start

• Harbor Demo Group and Harbor Soho are active in the app context, with `orgId`, `locationId` and an occurrence ID available.
• The service occurrence can be opened from the reservations calendar or from the `reservations/:occurrenceId` deep link.
• The occurrence detail can load the `service_occurrences` record and its linked `calendar_event`.
• The operator has `reservation:manage` for Harbor Soho to open Configurations and run the change. View-only reservation access can inspect the detail but cannot run this action.
• Before recording the mutating GB capture, prepare `BOOKING_DETAIL_OCCURRENCE_ID` with `acceptance_state=open` and reopen it at the end.

Instructions

1. 1.

   Open the service occurrence

   From the reservations calendar, select the Soho lunch service occurrence, or open the direct occurrence detail link. Confirm that the occurrence header has loaded and shows the current service state before changing it.

2. 2.

   Open Configurations

   Use `Configuraciones` in the occurrence detail header. The button is available to operators with reservation management access; view-only operators can inspect the occurrence but cannot run the acceptance change.

3. 3.

   Mark the occurrence complete

   When the occurrence is open, choose `Marcar completo`. Antylogic updates only this occurrence, not the recurring service series, and blocks new confirmed reservations for this date and time.

4. 4.

   Reopen reservation acceptance

   When the occurrence is complete, open Configurations again and choose `Permitir más reservas`. The same occurrence returns to open acceptance, so new confirmed reservations may be accepted again when capacity, public booking mode and other reservation rules allow them.

5. 5.

   Treat failures as unchanged

   If the update fails, stay on the occurrence detail and wait for the error toast. Do not assume the state changed until the header refreshes and the menu label switches to the opposite action.

Validations and limits

• The only persisted acceptance states for this action are `open` and `completed`.
• The app does not call the API when the occurrence ID is missing, the occurrence has not loaded or the operator lacks management access.
• The frontend sends `PUT /api/app/{orgId}/{locationId}/service-occurrences/{occurrenceId}/acceptance-state` with `{ acceptance_state: "open" }` or `{ acceptance_state: "completed" }`; the backend also supports `PATCH` for the same route.
• `completed` is normalised to `is_full=true`; `open` is normalised to `is_full=false`.
• A completed occurrence blocks new confirmed reservations and is excluded from public bookable service availability, but existing reservations are not created, cancelled, moved or confirmed by this action.
• The backend may restore or recalculate waitlist mode while updating the occurrence, but reservations are only read for that decision.
• The action changes only the selected occurrence. It does not update the recurring service, calendar recurrences, calendar overrides or the linked calendar event definition.
• The backend allows `reservation:manage` or `optimization:manage`, but the reviewed app screen exposes the action only through `reservation:manage`.
• No dedicated confirmation modal was observed for marking complete or allowing more reservations, so operators should verify the selected service before tapping the menu action.

Expected result

The selected service occurrence is closed or reopened for confirmed reservation acceptance, the occurrence caches refresh, and the Configurations menu switches between `Marcar completo` and `Permitir más reservas` for the next reversible action.