Release 1.72.3
Release Notes - Seatmap Platform
Version 1.72.3 - 2026-09-02
Release Focus: Changes to an already-published plan reach the booking renderer immediately instead of waiting out a cache window, organisation administrators can regenerate a schema preview themselves, and editor sessions opened from a cached integration URL complete sign-in. Delivered as a patch on top of the 1.72 line.
MetaTitle: Release 1.72.3: Immediate Seatmap Updates - Seatmap.pro
MetaDescription: Seatmap 1.72.3 sends published seatmap changes to the booking renderer straight away, lets organisation admins regenerate previews, and repairs cached sign-ins.
What’s Fixed
Published seatmap changes reach the booking renderer immediately
Saving a plan that is already published now updates the booking seatmap straight away. Renamed sections, moved seats, changed capacity and updated backgrounds could previously take up to an hour to appear for bookers, and regenerating the preview did not shorten the wait.
Bookers see the saved plan within about 30 seconds. If the platform cannot reach its cache at that moment the save still succeeds and the change appears once the cache entry expires.
Issue: SEAT-1233.
Organisation admins can regenerate a schema preview
The Regenerate control on a schema card is available to organisation administrators, and is shown only to the roles that can use it. Regeneration is limited to schemas the caller’s own organisation owns; platform operators can regenerate a single schema for any organisation they support.
Preview images already refresh on their own after every save, so this control is only needed to retry one that did not appear.
The job list, the single job view, the single-job restart and the organisation-wide restart remain operator endpoints and are scoped to the operator’s own tenant. A restart requested for an organisation in another tenant returns 403, and job listings show only the operator’s own tenant.
Issue: SEAT-1234.
Editor sessions opened from a cached integration URL keep working
An integration that opens the editor with the legacy token and refreshToken query parameters now completes sign-in even when the page was built more than five minutes earlier: the editor spends the refresh token supplied alongside the access token instead of returning the user to the login screen.
An expired or absent refresh token still returns the user to the login screen, unchanged. The one-time ssoCode handoff remains the recommended way to open the editor from a partner page.
Issue: SEAT-1232.
Affected products
booking-service— seatmap, payload and metadata cache entries are keyed consistently with the entries the editor removes on publish.editor-service— publishing a plan clears the booking caches once the save has committed; preview regeneration is scoped to the caller’s organisation.common-lib— cache names and key expressions are defined in one place and shared by both services.editor-client— sign-in from a legacytokenandrefreshTokenURL spends the supplied refresh token; the Regenerate control on a schema card is shown to the roles that can use it.
Upgrade
No API or database changes, and no action is required. The new behaviour applies on upgrade.
Deployments that run editor-service and booking-service against separate Redis instances should point both at the same instance, since the editor clears the entries the booking renderer reads.