Release Notes – v3.2.8-rc1

20 August 2026 (cbf844b)

Reservations Portal

Unable to search a booking via the external reference number

Jira: V3-249 | FD: 5385

• Historic orders searchable by external/trade-partner reference - Orders created before searchable reference columns were added now have their reference data populated through a post-deploy backfill, allowing searching by external reference (V3-249)

Infrastructure

• Post-deployment migrations - The deploy pipeline now supports post-migrations for long-running, non-blocking data backfills that run after the new application version goes live instead of blocking deploys (previously took ~2 hours on large datasets for reference backfills). These migrations are:
• Batched, idempotent, and resumable
• Run with transactions disabled so live applications aren't locked
• Emit structured events for Datadog alerting
• No user-facing impact (DEVOPS-659)

Release Notes – v3.2.8-rc2

27 August 2026 (d5f14ad)

Tower of London Booking Journey - Date Selection Fix

Jira: CORE-9050 | FD: 5603

• Issue: Users intermittently encountered a greyed-out "Confirm Selection" button on the Tower of London booking page. This occurred when a date was selected and the user subsequently navigated to a different month in the calendar, causing a deadlock in the selection process.
• Resolution: The booking component has been updated to ensure that a selected date and its associated time slots persist during month navigation. The "Confirm Selection" button now remains active, allowing users to proceed with their originally selected date regardless of calendar browsing.

HRP Guided Tour and B2C Admission - Email and Ticket Generation

Jira: CORE-9045 | FD: 5566

• Issue: Several instances were reported where confirmation emails and tickets were not generated following successful payment. This was attributed to two factors: orders being processed without mandatory customer details and a service limitation affecting the generation of emails for large orders.
• Resolution:
• Mandatory Customer Details: A validation guard has been implemented for B2C orders to ensure customer information is captured before an order can be placed.
• Email Payload Optimization: The system now correctly handles larger order payloads, ensuring that confirmation emails and ticket PDFs are generated and sent successfully for all booking sizes.

Release Notes – v3.2.8-rc3

1 September 2026 (61ed9ed)

HRP - Direct debit frequency for cancellations in reporting

Jira: CORE-8994 | FD: 5414

Description of fix: Resolved an issue where the "Direct Debit Frequency" field (e.g., Monthly, Quarterly, Annually) was appearing blank in the EFinancials report for cancelled memberships or patronages. The report now correctly populates this data for both active and cancelled records.

Guide to testing:

1. Identify or purchase a membership/patronage via Direct Debit.
2. Cancel the membership/patronage.
3. Run the EFinancials report and verify that the "Direct Debit Frequency" column is correctly populated for the cancellation line.

HRP RES: Order Email updates for existing Customer Accounts

Jira: CORE-8991 | FD: 5290

Description of fix: Fixed a validation error that prevented users from updating a Membership Order Email if the new email address was already associated with a different Customer Account. The system now allows these updates, facilitating smoother reassignment of orders to existing accounts.

Guide to testing:

1. Identify a Customer Account with an existing email address.
2. Locate a separate membership order with a different email.
3. Attempt to update the Membership Order Email to the email address from step 1.
4. Verify the update is successful and the "Email Address already in use" error no longer appears.

Expose GET markets/{marketId}/promos endpoint

Jira: CORE-8998 | This supports work being done to fix FD case: 5382

Description of fix: Technical update to expose the promotions endpoint for specific markets. This allows external integrations and internal services to programmatically retrieve a list of available promotions associated with a specific market ID.

Guide to testing:

1. Using an API client (like Postman), call the GET markets/{marketId}/promos endpoint.
2. Verify that the response returns the expected list of active promotions for the provided market ID.

POS-specific Promotion Filtering

CORE-5918

Description of fix: Updated the POS application logic to ensure it retrieves only promotions specifically configured for the Point-of-Sale channel, rather than a general list of all system promotions. This ensures POS users only see relevant discounts and offers.

Guide to testing:

1. Log into the POS application.
2. Navigate to the promotions/discounts section.
3. Verify that only POS-eligible promotions are visible and that web-only or general promotions are correctly filtered out.

Release Notes – v3.2.8-rc4

3 September 2026 (25c26a0)

Unable to search a booking via the external reference number

Jira: V3-249 | FD: 5385

• We’ve improved order search so customers can more reliably find new and updated orders using their reference numbers, including order references and booking references.
• Imported orders now keep both order-level and item-level references, which helps ensure they remain searchable and easier to trace later.
• Existing orders already in the system will also become searchable by reference again once the regular post-deploy backfill completes.

Release Notes – v3.2.8-rc5

11 September 2026 (40f5b59)

HRP - FOLLOW UP ISSUE HRP Guided Tour email/tickets not generating

Jira: CORE-9129 | FD: 5566

Description of fix: Resolved a crash in the ticket rendering service that occurred when generating PDFs for orders containing guided tour addons. The issue was caused by the system attempting to render a barcode for the tour, which does not have a ticket reference. The fix ensures PDFs are generated successfully with admission QR codes while correctly omitting barcodes for non-ticketed tours.

Testing guidance:

1. In the Reservations app, book an admission (e.g., Hampton Court) and add the "Hampton Court Palace Guided Tour - 1.5 Hour" addon.
2. Select Pay by email and complete the payment via the link.
3. Verify the confirmation email is received with a PDF attachment.
4. Confirm the PDF contains admission tickets with QR codes and a guided tour page without a barcode.
5. Perform a regression check on plain admission orders to ensure QR codes still render correctly.

HRP - Efin - Sales & exceptions report - Abandoned Orders

Jira: CORE-9053 | FD: 5602

Description of fix: Fixed a critical bug where duplicate POS card charges were being accepted and recorded, leading to inflated order values in the Sales & Income Exceptions report. The system now includes a validation check that rejects any payment attempt that would cause the total payments to exceed the amount owed.

Testing guidance:

1. In POS, create a cart and pay the full balance using a card.
2. Attempt to submit the same card payment a second time (e.g., by re-tapping or replaying the request).
3. Verify the second charge is rejected with a 422 error: "The total value of payments exceeds the amount owed."
4. Run the Sales & Income Exceptions report for the date of the test.
5. Verify that the order does not appear with an inflated amount and that fully paid or cancelled orders net to £0.

Release Notes – v3.2.8-rc6

16 September 2026 (f844258)

This release is focused on the issues reported since the V3 rollout, with the bulk of the work in Reservations and in the tools front-of-house teams use every day.

Contact centre and membership teams benefit most: reporting filters and the date picker in Reservations now behave as expected, scheduled membership downgrades no longer strip members from the current term, and manual renewals record the correct staff user against the CRM integration. Front-of-house sees a cleaner promotions list on POS and a cap on manual walk-up entries so a mistyped number can no longer distort attendance reporting.

Online, the extra-event recommendation in checkout now accepts carer tickets. Two changes are platform performance and stability work with no visible change to day-to-day use. Two actions are needed on the client side: POS devices must be on app version 3.0.15.2 or later for the promotions change to take effect, and the membership CRM fix applies only to renewals processed after deployment, so any records already affected will need correcting manually.

POS

Expired and non-POS promotions appearing in the promotions pick list

Jira: CORE-8990 | FD: 5382

Issue When staff opened the promotions pick list on POS, the list included old promotions that were no longer active, along with promotions that had never been enabled for the POS channel. Removing the market from a promotion, or removing it from all channels and markets, did not take it off the list. Selecting one of these promotions was blocked at the point of applying it, but the list itself had become long and difficult to work with.

Fix The promotions list is now requested for the current site and market each time the screen is opened, rather than being served from a full catalogue held on the device and refreshed once every 24 hours. Promotions that are not offered for that market and channel no longer appear. Changes made in Admin or Reservations are picked up the next time the screen is opened, with no overnight wait and no sync required. The list is also now sorted alphabetically. Applying a promotion is unchanged: codes can still be typed or scanned, and invalid or ineligible codes are still rejected at the point of applying. This change requires POS app version 3.0.15.2 or later.

Expired promos are not removed from the list at this point, that is a change and will need to be dealt with separately.

Testing

1. Log in, select the market and location, start a sale and open Select promotion. Confirm the list loads and is in alphabetical order.
2. Confirm a valid POS promotion appears in the list, select it and apply it.
3. Compare the POS list against the Reservations list for the same market. Promotions that Reservations does not offer should not appear on POS.
4. In Admin or Reservations, expire a promotion or remove the POS channel from it, then reopen Select promotion on POS. The change should be reflected immediately.
5. Type or scan an invalid or expired code and apply it. It should still be rejected.
6. Complete a sale without opening the promotions list to confirm the standard basket flow is unaffected.

Scanning

Manual walk-up attendance entries capped at 10, and an erroneous record corrected

Jira: CORE-8870 | FD: 4985

Issue A single manual walk-up entry recorded at Hampton Court on 12 June 2026 logged 70,005 Blue Peter Child tickets, which distorted visitor reporting. There was no limit on the number that could be entered against a manual walk-up type.

Fix Two changes. The incorrect attendance record was removed from the production database on 15 September 2026, so it no longer appears in reporting.

Separately, manual walk-up entries are now capped at 10 per submission, across every walk-up type and every gate. Attempting to submit more than 10 shows a message confirming the attendance has not been submitted, and no record is created. The cap applies only to manually entered walk-ups. Ticket redemption by scanning is unaffected, including tickets configured with a passenger count above 10, and membership guest allowances continue to be enforced as before.

The cap is applied by the server, so a device working offline will accept an entry above 10 locally and confirm it on screen; that entry is then discarded when the device reconnects and will not appear in reporting.

Testing

1. On POS, open Add Walkups, select a walk-up type, enter 11 and submit. The entry should be rejected and no row should appear in the attendance report.
2. Repeat with 10 and with 1. Both should be accepted and appear in reporting with the correct passenger count.
3. Repeat the rejection test with two or three other walk-up types to confirm the cap applies across the board.
4. Scan a ticket configured with a passenger count above 10. It should redeem normally and the attendance record should be created with the configured count.
5. Scan a membership card, add guests up to the entitlement allowance and submit. The allowance should still be enforced as before.
6. Suggested: check the walk-up attendance report for the relevant sites to confirm the 12 June record is no longer present.

Reservations

Orders with Gift Aid and a non-UK address could not be amended

Jira: CORE-9025 | FD: 5499

Issue Customers with a non-UK address had been able to add Gift Aid to their booking. When those customers later asked to amend the booking, the system recognised the address as non-UK and blocked the amendment, and the Gift Aid could not be removed. The contact centre had no route through other than refunding the order in full and asking the customer to rebook.

Fix Gift Aid remains restricted to UK addresses. Adding Gift Aid to an order with a non-UK address is still blocked, and changing the address on a Gift Aided order to a non-UK one is still blocked. Orders with a UK address, and orders with a non-UK address and no Gift Aid, are unchanged.

Testing

1. Attempt to add Gift Aid to an order with a non-UK address. It should still be blocked with the UK-only message.
2. On an order with Gift Aid applied, change the address to a non-UK one. It should still be blocked.
3. Amend an order with Gift Aid against a UK address. This should work as before.
4. Add Gift Aid to an order with a UK address. This should still be allowed.
5. Amend an order with a non-UK address and no Gift Aid. This should work as before.
6. Suggested: attempt to amend one of the originally reported bookings, or a like-for-like test order with Gift Aid and a non-UK address, and confirm the amendment completes.

Date picker and filter fields in reporting

Jira: CORE-9029 | FD: 5521

Issue Two problems were reported across all reports in Reservations. Using the arrows either side of the month name in the date range calendar closed the calendar instead of moving to the next or previous month, so users had to type dates in by hand. Separately, filter value fields accepted only one character at a time, with the field losing focus after each keystroke and needing to be clicked again.

Fix The calendar now stays open while navigating between months, and dates selected after navigating are retained in the date range. Filter value fields keep focus, so a full word can be typed in one go. This applies to both free-text filters and the search box used with the "is" and "is not" operators.

Testing

1. Open a report, use EFinancials with Order Details, and open the filter panel.
2. Add a rule for Description with the operator "contains", then type a full word into the value box in one go without clicking back into it.
3. Add a rule using the "is" or "is not" operator, click the value box and type several characters to search the suggestions.
4. Open the date range field, select a "from" date, then use the month navigation arrows to move to another month and select a "to" date. The calendar should stay open and both dates should be retained.
5. Suggested: repeat step 4 on two or three other reports to confirm the behaviour is consistent.

Scheduled membership downgrades removed members from the current term

Jira: CORE-9033 | FD: 5529

Issue When a membership covering more than one person was scheduled to downgrade at the end of the term, for example Family 2 Adults downgrading to Individual, the additional members were removed from the membership immediately. The membership title correctly remained on the current product, but only the lead member was shown, so the additional members appeared to have lost their entitlement before the term had ended.

Fix Scheduling a downgrade no longer affects the current term. All members remain on the membership with their details intact until the term ends, and the entitlement of the new product applies only from renewal. The order page continues to show the current membership title, the full list of additional members, and a notice confirming the downgrade is scheduled, with the option to cancel it. Applying a downgrade immediately rather than at renewal is unchanged and still removes the additional members at the point the change is made.

Testing

1. Create or open a Direct Debit membership covering more than one person, with at least one additional member recorded.
2. Select Change membership type, choose a lower-level membership, and select the option to apply the change at renewal.
3. Reload the order. The membership title, the additional members and their details should all still be present, alongside the scheduled downgrade notice.
4. On a separate order, run the same change but apply it immediately. The additional members should be removed, as before.
5. On a third order, select a lower-level membership but back out of the change without confirming. All members should remain.
6. Suggested: edit an additional member's details on a membership with a scheduled downgrade and confirm the change saves normally.

Admin

Users signing in with SSO for the first time were not always created in Admin

Jira: CORE-8729 | FD: 4844

Issue When a new user signed in for the first time using single sign-on, they did not reliably appear in the unassigned users list in the Admin portal, so administrators could not assign them permissions. In several cases the user had to select the sign-in button repeatedly, sometimes over more than one day, before the unassigned user record was created.

Fix The change is intended to create the unassigned user record on the first successful single sign-on, so the user appears in the unassigned users list straight away and can be assigned roles without repeated sign-in attempts.

This change requires client UAT, as Expian does not use SSO.

Testing

1. Use a single sign-on account that has never signed in to the environment before. This only tests correctly with an account that is completely new to the system.
2. Select the SSO button on the sign-in screen and complete the sign-in once. Do not select it repeatedly.
3. As an administrator, open Users and then Unassigned users. The new user should be listed, with no roles assigned.
4. Assign roles to that user and save, then ask them to sign in again. They should move out of the unassigned list and be able to access the portal.
5. Sign in with an existing SSO account that already has roles. Access should be unchanged.
6. Sign in with a standard email and password account. This should work exactly as before.

Please note that step 1 can only be run once per account. To repeat the test, a further account that is new to the environment is needed.

Backend

Manual membership renewals recorded the wrong user against the CRM integration

Jira: CORE-9044 | FD: 5560

Issue Memberships renewed manually in Reservations were sent to the CRM with the wrong staff details. The user location was recorded as the system account rather than the department of the member of staff processing the renewal, and the user code was recorded as the system process identifier rather than that person's user ID. Eight bookings were identified as affected following the V3 rollout.

Fix Manual renewals now record the member of staff who processed the renewal, and those details are passed to the CRM. No change was needed to the CRM integration itself. This fix applies from deployment onwards only. The bookings already affected will keep their current CRM values unless they are corrected directly in the CRM.

Testing

1. Suggested: process a manual membership renewal in Reservations, paid by card, signed in as a named member of staff.
2. Suggested: check the resulting record in the CRM and confirm the user location shows that person's department and the user code shows their user ID.
3. Suggested: repeat with a second member of staff from a different department to confirm the values follow the signed-in user.

Improved caching of booking options for signed-in members

Jira: CORE-8004

Issue Booking searches made by signed-in members with a membership, patron or voucher entitlement were cached separately for every individual customer, rather than once for each membership type. Every member's first search therefore had to be calculated from scratch, and the stored results built up quickly during busy periods, which increased the load on the platform when large numbers of members were booking at the same time.

Fix Booking search results are now shared across customers holding the same entitlement, rather than being stored per customer. There is no change to what members see or to how they book. The benefit is faster responses during high-volume member activity and reduced risk of the platform being put under strain by member-only on-sales.

Testing

1. Suggested: complete a booking as a signed-in member and confirm the correct entitlement pricing and ticket types are offered.
2. Suggested: repeat with members on two or three different membership tiers and confirm each sees the entitlement appropriate to their own tier.
3. Suggested: complete a booking as a guest, with no account signed in, and confirm no change to what is offered.

This will be most evident during large onsales for people holding entitlements trying to access a member only entitlement. There is accompanying documentation being produced to explain the problem this fixes in more detail.

B2C

Carer tickets could not be added to the extra event recommendation during checkout

Jira: CORE-8882 | FD: 5049

Issue When a customer added a River Tour to their basket through the extra event recommendation during checkout, including a River Tour Carer ticket stopped them progressing. After selecting an arrival time, the Confirm Selection button stayed greyed out. Removing the carer ticket allowed the booking to continue. Booking the River Tour on its own, outside the recommendation, was not affected, and the same combination worked in Reservations.

Fix Adding a ticket type that is at its per-booking limit, such as the carer ticket, no longer blocks the recommendation. Once an arrival time is selected, Confirm Selection becomes available and the tickets are added to the basket as expected. The per-booking limit itself is unchanged and is still enforced, so the quantity cannot be increased beyond the configured maximum.

Testing

1. Start an order for Tower of London admission, add tickets, select a date and time and continue through checkout until the River Tour recommendation appears.
2. Add one River Tour Adult and one River Tour Carer, then select an arrival time. Confirm Selection should become available and the tickets should be added to the basket.
3. Repeat with a child ticket and a carer ticket, which is the combination originally reported.
4. Add only a carer ticket, with no adult or child, and confirm the selection can be added.
5. Add two adult tickets with no carer and confirm this still works as before.
6. Try to increase the carer ticket quantity beyond its limit. The control should not allow it.
7. Book the River Tour as a standalone product with an adult and a carer ticket and confirm no change in behaviour.
8. Complete a full purchase with a carer ticket added through the recommendation and confirm both River Tour tickets appear correctly on the order, the tickets and the confirmation email.

Infrastructure

Jira: CORE-9094

Issue Searches covering unusually long date ranges caused the platform to store a very large volume of duplicated data in its cache, which in turn caused memory pressure and, in one case, errors on live services.

Fix The shared data used by a booking search is now stored once rather than being repeated for every date in the range, and the handling of cache connection failures has been made more resilient. There is no change to day-to-day use of the platform. The benefit is greater stability under heavy or unusual search traffic.

Testing

1. Suggested: no client testing is required for this change. It will be monitored on our side following deployment.

Review notes (internal, delete before sharing)

Release Notes – v3.2.8-rc7

17 September 2026 (ea0b8ac)

This candidate adds the two fixes that were held back from rc6 while they completed QA. Both have now passed and were deployed to the HRP UAT environment on 17 September. rc7 otherwise contains exactly the same content as rc6, so everything listed under rc6 still applies and rc7 is the build to test against and deploy.

Membership and contact centre teams benefit most: customers who abandoned an online account sign-up part-way are no longer locked out of buying a membership, and staff can once again sell to them on POS and in Reservations without hitting the "User already exists" message. Finance benefits from ancillary items such as guidebooks now reporting against their configured cost centre in EFinancials rather than as Unmapped.

Customer accounts

Membership sale blocked by "account already exists" after an abandoned sign-up

Jira: CORE-9009 | FD: 5430

Issue Customers who started creating an online account and stopped at the "enter verification code" step were left in a limbo state. The account existed in the sign-in system but no customer record had been created. Any later attempt to sign up with the same email failed with "an account with the given email already exists", staff selling a membership to that email on POS or in Reservations were shown "User already exists, please use the book on behalf of a customer feature instead", and the customer could not be found in Select Customer to book on their behalf. The only route out was for the customer themselves to request a new verification code, which the error messages did not explain.

Fix An unfinished sign-up no longer blocks the customer. Signing up again with the same email clears the abandoned attempt and sends a fresh verification code, and completing it creates the account normally. Selling a membership to that email on POS or in Reservations now proceeds to payment and creates the customer account, which then appears in Select Customer and in Customer Accounts. Customers already stuck in this state are recovered by the same change. Existing, complete customer accounts are handled as before: entering a known customer's email with different names still shows the "User already exists" message and their recorded details are not altered.

Testing

1. On the booking site, create an account with a new email address and, at the "enter verification code" screen, select "Back to login" without entering the code. In Reservations, search Customer Accounts for that email. No results should be found at this point.
2. In Reservations, start a new membership booking with Direct Debit, enter that same email with a first and last name, and continue. No "User already exists" message should appear and the checkout should reach the payment step.
3. Search Customer Accounts for the email again. Exactly one account should exist with the names entered at the till, and an invitation email with a temporary password should have been received.
4. On the booking site, create an account with a second new email, abandon at the code screen, then create an account again with the same email and any password. No "account already exists" error should appear, a new code email should arrive, and entering it should complete the account and sign the customer in. Signing in later with the second password should work.
5. In Reservations, start a membership sale for a third new email, reach payment and abandon the cart by leaving the page. Start the same booking again with the same email. Checkout should continue and Customer Accounts should show one account for that email, not two.
6. Pick an existing, complete customer and start a membership sale entering their email with different first and last names. The "User already exists" message should still appear and the customer's original names should be unchanged. Booking on their behalf through Select Customer should work as before.
7. On POS, start a membership sale using an email that was abandoned at the online code screen and continue to payment. No "User already exists" dialog should appear, the sale should proceed to Interbacs, and the account should then be findable in POS Search User and in Customer Accounts.
8. Suggested: sign in with an email whose sign-up is still unconfirmed. It should still route to the "enter verification code" screen with a Resend Confirmation Code option, as before.

Please note that steps 1, 4, 5 and 7 each need an email address that is completely new to the environment.

Reporting

Ancillary item sales reporting as Unmapped in the EFinancials reconciliation report

Jira: CORE-9060

Issue Some ancillary items, for example the Kew Palace and Banqueting House guidebooks, had a Cost Centre Code and Account Code configured in Admin under Integrations, but sales of those items appeared in the EFinancials reconciliation report with a blank title and a cost centre of Unmapped. The report relied on a shared lookup that was not always up to date, so codes configured or changed recently were not visible to it.

Fix Sales of ancillary items now resolve to the item's title and its configured cost centre and account code without depending on that shared lookup being refreshed. This applies to sales made on POS, in Reservations and online, including ancillary items added through an amendment. Items with no codes configured continue to report as Unmapped, as intended.

During testing, removing an option from an existing ancillary item in Admin produced an error. This is unrelated to the reporting fix and is being handled separately under CORE-9152.

Testing

1. In Admin, open Extras and then Addons, create a new ancillary item with a title and at least one pricing option, set the Addon Cost Centre Code and Account Code under Integrations, and save.
2. Sell that item on POS or in Reservations, then run the EFinancials report in Reservations for today. The sale line should show the item's title and the configured cost centre and account code, not a blank title with Unmapped.
3. Open an existing ancillary item that already has sales, rename or reprice one option, save, sell it again and re-run the report. The new sale should still resolve to the item's title and cost centre.
4. Open or create an ancillary item with five or more options, make a small change and save. The save should complete promptly with no error, other Admin pages should keep loading normally, and running the EFinancials report straight afterwards should show the item mapped correctly.
5. Online, add an ancillary item to a normal ticket booking and complete the order. The add-on should price and complete exactly as before.
6. Repeat one sale in Reservations and one on POS, including an amendment that adds an ancillary item. In every case the EFinancials line should carry the correct title and cost centre.
7. Suggested: re-run the reconciliation report for Kew and Banqueting House after deployment and confirm new guidebook sales no longer appear as Unmapped.

Release Notes – v3.2.8-rc8

22 September 2026 (5488022)

This candidate contains no new work. It answers the two items HRP marked as failed during UAT of rc7: expired promotions were still appearing in the POS promotions list, and Gift Aid could still be claimed online with a non-UK address. Both fixes have passed QA and were deployed to the HRP UAT environment on 22 September. Everything else listed under rc6 and rc7 is unchanged, and rc8 is now the build to test against and deploy.

Front-of-house sees a promotions list on POS that drops expired promotions as soon as they expire, with no need to remove the POS channel by hand. Online, customers with an overseas address can no longer claim Gift Aid at checkout, which closes the gap that was creating orders the contact centre could not later amend.

POS

Expired promotions still appearing in the POS promotions pick list

Jira: CORE-8990 | FD: 5382

Issue Following the rc6 change, HRP UAT confirmed that removing the POS channel from a promotion hid it from the pick list and that the list was in alphabetical order by external ID. However, expiring a promotion did not remove it from the list, so staff had to remove the channel manually to hide it, and one promotion with every channel removed in Reservations was still shown on POS.

Fix The promotions list on POS and in Reservations now applies the same rules as applying a promotion. A promotion appears only if the caller's channel is enabled on it, its purchase window covers today, and any visit-date condition has not passed entirely. Expired promotions therefore disappear from the list as soon as they expire, and promotions saved with no channels at all are no longer listed anywhere. The list remains ordered alphabetically by external ID. Applying a promotion is unchanged: invalid, expired or ineligible codes are still rejected at the point of applying. POS devices still need app version 3.0.15.2 or later.

Testing

1. In Admin or Reservations, expire a promotion that currently appears on POS, then reopen Select promotion on POS. The expired promotion should no longer appear.
2. Close and reopen the POS app, then check Select promotion again. The expired promotion should still be absent.
3. Set a promotion's end date to a date in the past rather than expiring it explicitly, then reopen Select promotion on POS. It should no longer appear.
4. Try to apply an expired promotion to a sale on POS by typing or scanning its code. It should be rejected.
5. Remove the POS channel from a promotion that currently appears, then reopen Select promotion. It should be hidden, as before.
6. Re-add the POS channel to that promotion and reopen Select promotion. It should reappear.
7. Suggested: check that the BLFOODSAT26 promotion reported during UAT, which had all channels removed, no longer appears on POS or in the Reservations pick list.

B2C

Gift Aid could still be claimed online with a non-UK address

Jira: CORE-9025 | FD: 5499

Issue The rc6 change blocked Gift Aid on non-UK addresses in Reservations, but HRP UAT found that the online checkout still allowed it. A customer could add a donation, claim Gift Aid, then enter a United States address on the Contact Details screen and continue to payment. The resulting orders carried a Gift Aid declaration against an overseas address, which is the situation that had left the contact centre unable to amend them. The rule was only checking a shipping address, and the online checkout collects a billing address only.

Fix The UK-only Gift Aid rule now applies to the customer's home address whichever way it is collected: the shipping address where one is entered, otherwise the billing address. Online, entering a non-UK country on the Contact Details screen with Gift Aid claimed shows the "Gift Aid can only be claimed on UK addresses" message against the address and disables Continue to payment until the country is changed back or Gift Aid is removed. The same check is enforced by the server, so it cannot be bypassed. Orders that already carry a declaration against a non-UK address remain amendable and cancellable, as delivered in rc6.

Testing

1. Online, select a ticket for a product with a donation available, say yes to the donation and claim Gift Aid. On Contact Details, set the country to the United States and complete the address, then accept the terms. The UK-only message should appear against the address and Continue to payment should be disabled.
2. Repeat with a valid UK address. There should be no error and the order should complete with Gift Aid applied.
3. Select a ticket without claiming Gift Aid, enter a United States address and continue. The order should complete normally with no Gift Aid message.
4. Claim Gift Aid, enter a UK address, then change the country to the United States. The message should appear and Continue to payment should be disabled. Changing the country back to the United Kingdom should clear it.
5. Suggested: repeat step 1 using the address finder rather than typing the address manually, to confirm both entry routes are covered.
6. Suggested: open one of the orders created during UAT with Gift Aid and a US address, for example DVOARMYHWTB1I, and confirm it can still be amended and cancelled.

Release Notes – v3.2.8-rc9

22 September 2026 (1056004)

This candidate contains one fix and nothing else. It answers the remaining item HRP marked as failed in UAT: orders that already hold Gift Aid against a non-UK address still could not be amended in Reservations. Everything else listed under rc6, rc7 and rc8 is unchanged, and rc9 is now the build to test against and deploy.

The contact centre benefits: the orders that started this ticket, with Gift Aid claimed against an overseas address, can now be amended, and the agent is asked whether to keep or remove the Gift Aid as part of the amendment.

Reservations

Orders with Gift Aid and a non-UK address still could not be amended

Jira: CORE-9025 | FD: 5499

Issue The rc6 change was intended to leave orders that already carried Gift Aid against a non-UK address amendable while blocking any new declaration. HRP UAT found that amending such an order in Reservations still showed the "Gift Aid can only be claimed on UK addresses" message on the address step and disabled Continue to payment, with no way to remove the Gift Aid. The server was accepting the amendment; the block came from the Reservations screen comparing the wrong address. Where an order had separate shipping and billing addresses, the amend flow was showing a copy of the billing address in the shipping form, and where an order had no stored shipping address at all, it compared against an empty country, so the rule always fired.

Fix The amend flow now shows the stored shipping and billing addresses as they were saved, and uses the same address as the server to decide whether the Gift Aid rule applies: the shipping address where one was collected, otherwise the billing address. When an order already holds Gift Aid against a non-UK address, the Gift Aid prompt re-opens during the amendment so the agent can either keep the existing consent or withdraw it. New orders with a non-UK address are still blocked from claiming Gift Aid, and changing the country to a non-UK one during an amendment is still blocked, as before. Orders with a UK address and orders without Gift Aid are unchanged.

Testing

1. In Reservations, open one of the orders created during UAT with Gift Aid and a US address, for example DVOARMYHWTB1I or DVO3BGTIZIU86, and start an amendment. The address step should no longer show the UK-only message and Continue to payment should be available.
2. Continue the amendment. The Gift Aid prompt should open with the option to keep the existing Gift Aid or remove it. Complete the amendment once with each choice and confirm the order reflects it.
3. Amend an order that has different shipping and billing addresses. Both addresses should show as they were saved, not a copy of the billing address in both.
4. Amend an older order that has a billing address but no shipping address. The shipping form should be pre-filled from the billing address and the amendment should complete normally.
5. Start a new order with Gift Aid claimed and enter a non-UK address. It should still be blocked with the UK-only message.
6. Amend an order with Gift Aid against a UK address and change the country to a non-UK one. It should still be blocked.
7. Amend an order with Gift Aid against a UK address without changing the address, and amend an order with a non-UK address and no Gift Aid. Both should work as before.
8. Suggested: repeat step 1 on the booking site with a signed-in customer amending their own order, to confirm the same behaviour online.

Release Notes – v3.2.8-rc10

23 September 2026 (5c0a935)

This candidate changes direction on one item and adds nothing else. HRP confirmed after rc9 that production today accepts Gift Aid on a non-UK address with no warning, and that this is the behaviour they want to keep. The UK-only Gift Aid rule introduced in rc6 and widened in rc8 has therefore been removed entirely. Everything else listed under rc6 to rc9 is unchanged, and rc10 is now the build to test against and deploy.

For customers and front-of-house nothing about Gift Aid changes compared with production: a customer with an overseas address can claim Gift Aid online, in Reservations and on POS exactly as they can today. The contact centre keeps the improvements from rc9 to the amend flow, and gains a direct way to remove Gift Aid from an order without changing the booking.

Anyone who tested rc8 or rc9 and saw the "Gift Aid can only be claimed on UK addresses" message should expect it to be gone in rc10. That is intended.

Reservations

UK-only Gift Aid rule removed; Gift Aid consent can be withdrawn from the order page

Jira: CORE-9025 | FD: 5499

Issue The original problem was that orders holding Gift Aid against a non-UK address could not be amended. Earlier candidates addressed this by blocking Gift Aid on non-UK addresses at checkout, first in Reservations and then online. During UAT, HRP confirmed that production accepts Gift Aid on a non-UK address with no warning and that this must stay as it is. Separately, the rc9 route for removing Gift Aid during an amendment only worked when the booking itself was also being changed, so there was still no way to simply remove the Gift Aid from an affected order and leave the booking alone.

Fix The UK-only rule has been removed from the checkout and from the server. Claiming Gift Aid with a non-UK address is accepted again on new orders and amendments, online, in Reservations and on POS, with no message shown. Address fields are validated exactly as they were before this ticket. Two improvements from rc9 remain: when an amendment starts, the shipping and billing addresses show as they were saved on the order, and amending an order that holds Gift Aid against a non-UK address re-asks the Gift Aid question so it can be withdrawn. New in this candidate, the "GiftAid Consent Provided" checkbox on the order page in Reservations can be unticked for an order whose Gift Aid sits against a non-UK address, even where the tenant setting normally locks that checkbox, with the usual confirmation prompt. This lets an agent remove the Gift Aid and then amend the order as normal. Granting consent remains locked as configured, and orders with a UK address behave exactly as before.

Testing

1. Online, select a ticket, say yes to the donation and claim Gift Aid. On Contact Details enter a United States address and continue to payment. No Gift Aid message should appear and the order should complete with Gift Aid applied.
2. Repeat in Reservations for a new booking with a non-UK address and Gift Aid claimed. It should reach payment and complete with no message.
3. Leave a required address field empty or enter an invalid postcode and try to continue. The normal address validation should still apply.
4. In Reservations, open an order with Gift Aid against a US address, for example DVO3BGTIZIU86. The GiftAid Consent Provided checkbox should be enabled. Untick it, confirm, then amend the time slot. The amendment should complete with no Gift Aid message.
5. On the same kind of order, untick the checkbox and select No on the confirmation. Consent should remain in place.
6. Open an order with Gift Aid against a UK address. The checkbox should remain locked as it is today for non-member orders.
7. Open an order with a US address and no Gift Aid. The checkbox should not allow consent to be granted.
8. Amend an order with Gift Aid against a US address without unticking the checkbox first. The Gift Aid question should be asked again during the amendment, with the option to keep or remove it, and either choice should complete.
9. Amend an order with different shipping and billing addresses. Both should show as saved, not a copy of the billing address in both.
10. Suggested: complete a Gift Aid sale with a non-UK address on POS and confirm no message appears and the sale completes.

Release Notes – v3.2.8-rc11

28 September 2026 (1d7113d)

This candidate adds two fixes. The first addresses a live production problem found while investigating an HRP UAT order: guest customers paying by card could be shown "Unable to retrieve your order" after a successful payment, even though the order was placed, paid, ticketed and emailed. The second fixes a regression reported in UAT of rc10, where amending an online order in Reservations showed an empty shipping address form. Everything else listed under rc6 to rc10 is unchanged, and rc11 is now the build to test against and deploy.

Online customers benefit most: the confirmation page now loads reliably after a card payment, which on production affects roughly one in twenty-five card orders today, mostly on mobile. The contact centre gets the amend flow back to a single pre-filled address form for online orders.

Booking site

"Unable to retrieve your order" shown after a successful card payment

Jira: not yet raised | Found while investigating HRP UAT order DVOITEG8XJHUP

Issue After paying by card as a guest, some customers were shown "Unable to retrieve your order" instead of the confirmation page. The payment had gone through, the order was placed, and the tickets and confirmation email were sent, so the customer had a valid booking but no confirmation on screen. This happened when the card provider's own redirect back to the checkout arrived before the page had confirmed the payment itself, which is common on mobile after a bank verification step. The reloaded page no longer had the details it needed to look up a guest's order. Signed-in customers were not affected. On production this has affected around 4% of card orders over the last fortnight, roughly 60 customers a day.

Fix The checkout now keeps hold of the guest order details across the card provider's redirect, so the confirmation page loads whichever way the checkout returns. The details are kept in the browser for the current tab only and are not added to the return address. Pay-by-email links continue to work as before, and nothing changes for signed-in customers. The payment itself, the order and the confirmation email were already correct and are unchanged.

This fix was merged before being verified end to end, so the first step below is the important one.

Testing

1. On the booking site, as a guest and ideally on a mobile device, book a ticket and pay with a card that triggers a bank verification step. After completing the verification, the confirmation page should load with the order details. No "Unable to retrieve your order" message should appear.
2. Repeat on desktop. The confirmation page should load as before.
3. Start a card payment and cancel it, or use a card that declines. The checkout should return to the payment step cleanly.
4. Open a pay-by-email link from a Reservations order and complete the payment. The confirmation page should load as before.
5. Sign in as a customer and complete a card payment. Nothing should have changed.
6. Suggested: in Reservations, confirm the order from step 1 shows as paid with tickets issued and the confirmation email sent.

Reservations

Amending an online order showed an empty shipping address and could wipe the billing address

Jira: CORE-9025 | FD: 5499

Issue Reported during UAT of rc10. When amending an order that had been placed online, the checkout showed both address forms with the billing address filled in and the shipping address empty. Ticking "Billing address same as shipping address" then cleared the billing address as well. This affected any online order amended in Reservations, not only orders with Gift Aid, and was introduced by the rc9 change to how stored addresses are shown. Production is not affected.

Fix Online orders store an empty shipping address because the booking site does not collect one. The amend flow now recognises that as no shipping address, keeps the single address form as before, and pre-fills it from the billing address. Orders that genuinely have different shipping and billing addresses still show both, and orders with Gift Aid still show a separate home address form, both pre-filled. New orders are unchanged.

Testing

1. Place an order on the booking site without Gift Aid. In Reservations, open it, start an amendment and go to checkout. There should be a single address form, pre-filled with the customer's address. Ticking and unticking "Billing address same as shipping address" should not clear anything.
2. Repeat with an online order that has Gift Aid claimed. There should be two forms, both pre-filled.
3. Amend an order that was placed in Reservations with different shipping and billing addresses. Both forms should show the addresses as saved.
4. Amend an order placed in Reservations with the same shipping and billing address. There should be a single pre-filled form.
5. Place a new order in Reservations and enter a shipping address before continuing. The address entered should be kept and not replaced by the billing address.
6. Suggested: re-run the rc10 Gift Aid checks on an amended online order to confirm the Gift Aid prompt and the order-page checkbox still behave as described under rc10.

Release Notes – v3.2.8-rc12

28 September 2026 (cb5c020)

This candidate contains one fix and nothing else. UAT retested rc11 and still found the empty shipping address form when amending a Gift Aid order in Reservations. rc12 completes that fix. Everything else listed under rc6 to rc11 is unchanged, and rc12 is now the build to test against and deploy.

The contact centre benefits: amending an order in Reservations now shows the customer's address in both address forms, and ticking "Billing address same as shipping address" no longer changes anything because the two already match.

Reservations

Empty shipping address still shown when amending a Gift Aid order

Jira: CORE-9025 | FD: 5499

Issue After rc11, amending a Gift Aid order in Reservations still showed the billing address filled in and the shipping address empty apart from the country, with "Billing address same as shipping address" unticked. The rc11 change corrected the first point where the checkout fills in the shipping address, but there is a second. In Reservations, staff act on behalf of the order's customer, so the checkout always refills the billing address from the customer's profile, and that refill was resetting the shipping address to blank again.

Fix The shipping address is now set the same way at both points. Where the order has no real stored shipping address, the shipping form mirrors the billing address, including after the refill from the customer profile. Where the order does have a stored shipping address, it is kept, with anything already typed filling any gaps. On the order reported in UAT, both forms should now show the customer's address and ticking the checkbox should change nothing. New orders are unchanged.

This change is covered by automated tests on the new address logic but not by running the checkout screen itself, so retesting the reported order on UAT is the important step.

Testing

1. In Reservations, open the Gift Aid order reported in UAT and start an amendment. Go to checkout. Both address forms should show the customer's address. Ticking and unticking "Billing address same as shipping address" should not clear anything.
2. Amend an online order without Gift Aid. There should be a single address form, pre-filled with the customer's address.
3. Amend an order that has a genuinely different shipping address from its billing address. The stored shipping address should be kept, not replaced by the billing address.
4. Start a new order in Reservations and type a shipping address before continuing. The address entered should remain in the form.
5. Suggested: repeat step 1 on an order where the customer profile address differs from the address stored on the order, and confirm the shipping form follows the billing address shown.

HRP CRM Integration

27 August 2026

Dynamics 365 CRM sync failing — hrp_entrytype exceeds 100-char limit on hrp_scanningrecord

Jira: V3-233 | FD: 5294

Issue: Membership card scans from reissued cards were silently failing to sync to Dynamics 365, with the CRM rejecting records due to validation errors on the entry type field.

Fix:

• Root Cause: The warning text for reissued-card scans exceeded Dynamics' 100-character limit on the entry type field, causing records to fail validation (~8 scans/day since launch).
• Solution: Reissued-card scans now map to a standardized "Invalid Scan / Card Reissued" coded entry type, with both fields capped to prevent future message-length failures.
• Behavior: When a scan carries both a status and a reissued-card warning, the Invalid Scan status takes precedence. All other scan statuses remain unchanged.
• Data Migration: Approximately 133 previously held-up records can now be replayed from the queue. Records synced before this change will now display with the corrected entry type.

Testing: Jest test suite added with 20 tests covering:

• All reissued-card message formats
• Verification that existing scan statuses pass through unchanged (critical for HRP reporting)

Impact: Ensures all membership card scans—including reissued-card transactions—sync reliably to the CRM with correct categorization for reporting and analytics.

This feature will require a POS release (3.0.15+).