Antylogic
DemoApp login

399 operational guides

Docs sections
DocsCatalogues
Device

View Historical Catalogue

Open the catalogue attached to a past service occurrence in read-only mode, so an operator can check what was used without changing the active menu.

In this article

Use this guide when an operator needs to review the catalogue tied to a service that has already run. It is a traceability view, not an editing workflow.

For the GB demo, the example is Soho Menu at Harbor Soho. The verified entry point is a deep link or equivalent programmatic route with `readOnly=true` and `historicalOccurrenceId`; no visible menu entry was verified.

Before you start

  • Harbor Demo Group and the Harbor Soho location are selected.
  • The user is signed in to the authenticated app session under `/api/app`.
  • The user has `catalog:view` for the relevant scope. The UI also accepts `catalog:manage`, but manage access is not required for consultation.
  • The occurrence exists, belongs to a service calendar event, belongs to the active location when location-scoped, and is from a previous day in the event timezone.
  • The catalogue id in the route matches the `catalog_id` resolved from the occurrence or parent service event. If the service was versioned, that id may be a hidden or deleted snapshot catalogue.
  • For GB capture execution, `SETUP_CATALOG_HISTORY_OCCURRENCE_ID` must be supplied because it is not present in the provided runtime.

Instructions

  1. 1.

    Open the historical link

    Open the Harbor Soho catalogue detail route with `id`, `tab=catalogs`, `readOnly=true` and `historicalOccurrenceId`. This is the supported historical entry point for the documented action.

  2. 2.

    Let access and history checks run

    Antylogic loads the detail only when the user can view or manage catalogues in the current scope. The request sends `occurrence_id` to the catalogue API so the backend can validate the past service occurrence.

  3. 3.

    Review the locked catalogue

    Review the catalogue fields shown by the form, such as the name, default flag, image and visible product/type information. The historical view is read-only, so save, delete and product selection changes should not be available.

  4. 4.

    Handle missing results as validation failures

    If the catalogue does not appear, check the occurrence, the location, the past-day rule and the route id. When a service points to a snapshot catalogue, the route must use that resolved snapshot id, not necessarily the active catalogue id.

  5. 5.

    Return to active catalogue management

    Leave the historical detail and use the normal Catalogues area for active changes. Historical consultation does not update the current catalogue.

Validations and limits

  • The historical lookup only happens when `readOnly` is truthy and `historicalOccurrenceId` has a value.
  • The frontend route parameter is `historicalOccurrenceId`; the API query parameter is `occurrence_id`.
  • Backend access requires `catalog:view`; `catalog:manage` is not required for this read-only consultation.
  • The occurrence must resolve to an existing service event and must be from a previous day in that event timezone.
  • When the request is location-scoped, the occurrence location must match the active location.
  • The route catalogue id must exactly match the `catalog_id` resolved from the occurrence or service event payload.
  • The backend may return a deleted snapshot catalogue for traceability, but historical lookup is verified for catalogues only, not for related product or taxonomy detail handlers.
  • If `readOnly=true` is present without `historicalOccurrenceId`, the screen is locked but the API call is not historical. If `readOnly` is missing, the normal catalogue detail request is used.

Expected result

The operator can review the catalogue record used by the past service in read-only mode, then return to the active catalogue area without changing the current menu.

Related articles