Hawaii - Patch (22.16.1)

Release Summary

Kaptio is proud to announce this patch release for Hawaii. This release is intended to address issues with previous releases.

See Minor Changes and Bug Fixes for more information.

Sandbox Availability Date

2026-03-23

Release Type

Patch Release

Deployment Guide

See this page for the Hawaii Deployment guide.

Minor Changes

Feature: Group Tour

Exclude service lines with optional configs from the Price Model request (GTT-680)

Excluded service lines with optional configs from the Price Model Output calculation request

Add column "Day in Tour" to the builder for Price Models and Operational itineraries (GTT-681)

Enhanced the existing "Days" column in Itinerary Builder to work relative to a tour reference date.

Supports negative values, ranges, and direct editing. Day 1 is calculated from Tour Departure (Operational) or the first non-optional service (Price Model).

Populating tour_departure_id in API request for Operational Itineraries re-evaluation endpoint (KT-14115)

Fixed tour_departure_id population in the revaluation request

Troubleshooting of Operational Itinerary re-evaluation limit errors on Intrepid UAT (KT-14119)

Reduced heap size usage during Payment Schedules recalculation

Troubleshooting for Pax import heap size error (KT-14163)

Changed import Passengers flow to update operational Itineraries asynchronously to avoid heap size limit

Feature: Group Tour, Operational itinerary

Make 0 sell price for manually added lines in Operational Itinerary (GTT-651)

Implemented logic to enforce 0 sell price for manually added lines in Operational Itinerary

Re-evaluation performance improvement (PriceLineFactory) (GTT-678, GTT-663)

Reduced heap size usage of operational itinerary revaluation process

Script to update occupancy setup for "Standard" lines in Price Models (GTT-699)

Implemented a script to update occupancy setup for "Standard" lines in Price Models

Feature: Group Tour, Passenger Grid

Add special error and error code for Pax import when Operational Itinerary re-calculation status is "In progress" (KT-14161)

Added a special error and error category (business_rule) for Pax import when OI re-calculation status is "In progress"

Switch off validation for lead passenger for Operational Itineraries and Price Models (KT-14167)

Lead passenger assignment and validation logic has been disabled for passengers related to Operational or Price Model Itineraries

Feature: Group Tour, Payments

Payment Schedule Processing Optimization (KT-14018)

Problem/Background

Payment schedule recalculation always ran in sync, leading to unnecessary work during updates. There is no reason to run it in sync for Operational itineraries, and it serves no purpose for Price Model itineraries.

Solution

Payment schedule and recalculation flows now skip Price Model itineraries and honor async processing for Operational itineraries across itinerary, itinerary group, and passenger updates.

Impact

Operational updates are processed more efficiently with fewer unnecessary schedule recalculations, improving overall system responsiveness.

Add async capability for recalculateAssignments method is from PaymentScheduleImpl2 for operational itineraries (KT-14076)

Now recalculateAssignments method supports asynchronous execution

Feature: Passenger import

Remove validation for passenger-configuration assignment from passenger grid flow (GTT-700)

Removed validation for passenger-configuration assignment from passenger grid flow

Bug Fixes

If any crew member channel role exists the validation for operational itinerary should not fire. (GTT-632)

If any channel role exists then it should be enough to create operational itinerary and channel role assignment to the creq requirement record.

No price models available to select when assigning departures (GTT-669)

Fixed Assign Departures modal for the regions where it wasn’t working properly

Operational Itineraries created with wrong start date after implementation of optional configurations (GTT-670)

Fixed Operational Itinerary start date for PMs with optional services

Service with "Standard" qty behavior cannot be splitted (GTT-675)

Fixed Standard quantity behavior lines splitting and merging

New Passenger Grid: Multiple clicks on Save create duplicate passenger assignments (GTT-704)

Fixed multiple clicks on Save via disabling buttons

Configuration Assignment Management Refactor (KT-13923)

Summary

Refactored passenger configuration assignment logic to intelligently manage configuration states instead of recreating assignments on every import. This prevents unnecessary updates and maintains audit trails through soft-delete patterns.

What Changed

Previous behavior: When importing passengers with configurations, all existing assignments were deleted and recreated, causing unnecessary updates and loss of historical data.

New behavior: Configuration assignments are now intelligently managed:

  • Existing active assignments that are still needed: Left unchanged (no unnecessary updates)

  • Soft-deleted assignments that are needed again: Reactivated to 'Active'

  • New configurations: Created as new assignments

  • Unneeded configurations: Soft-deleted (Mode__c = 'Deleted') instead of hard-deleted

Impact

  • Reduced unnecessary DML operations during re-imports

  • Maintains audit trail through soft-delete pattern instead of hard-deletes

  • More efficient: only updates what actually changed

  • Prevents duplicate assignments when re-importing the same configurations

  • Cleaner data integrity with proper state management

Migration

None required. Existing assignments continue to work; new import logic applies automatically.

Configuration Assignment Processing Fix (KT-13956)

Summary

Fixed passenger import to properly distinguish between "configuration codes not provided" and "configuration codes provided but empty" when updating passenger records. This prevents accidental removal of passenger configurations during import updates.

What Changed

When importing or updating passengers with configuration assignments, the system now:

  • If ConfigCodes field is NOT included in the import: Leaves existing configurations unchanged

  • If ConfigCodes field IS included but empty: Removes all configurations for that passenger

  • If ConfigCodes field IS included with values: Updates configurations as specified

Previous Behavior

Omitting the ConfigCodes field would clear ALL existing configurations—​the same result as sending an empty list, creating risk of accidental data loss.

New Behavior

Omitting ConfigCodes treats it as "no change requested" for that field, preserving existing configurations and enabling safer partial updates.

Impact

Room and amenity assignments are preserved when updating other passenger fields Bulk imports no longer require providing ConfigCodes every time to avoid losing assignments More intuitive behavior: omitting ConfigCodes field = no change, rather than = clear all Improved data integrity during bulk passenger operations

Default passenger is not removed once the passenger sync was successful (KT-13957)

Passenger imports now remove all placeholder "TBD Traveller" passengers for an itinerary by matching any last-name prefix of "Traveller" rather than only the exact "Traveller 1". This ensures multiple placeholders (e.g., Traveller 1/2/3) are cleared when real passengers are imported.

Email is still displayed in the Kaptio UI passenger grid, even it was removed from the Starship (KT-13958)

Passenger fields can now be cleared via the import API and file imports (CSV/Excel): sending an empty string ("") or null for a field (e.g., Email, Passport) explicitly blanks it on the record. Fields omitted from the payload remain unchanged.

Supplier Invoice Lines "Dates with Time" and "Due Date" are calculating incorrectly (KT-14062)

Problem: "Dates with Time" and "Due Date" fields on Supplier Invoice Lines are calculating incorrectly.

Solution: Fixed the "after travel" date calculation logic for supplier invoice lines to correctly compute "Dates with Time" and "Due Date" fields.

Lead Passenger Assignment Fix for Multi-Role Import Scenarios (KT-14078)

Problem

When importing passengers into an itinerary that already contained passengers with different channel roles, the system could incorrectly assign lead passenger status to newly imported passengers, even when a valid lead passenger already existed on the itinerary.

This issue occurred specifically when:

  • An itinerary had existing passengers with valid lead-eligible roles (such as Adult)

  • One of those existing passengers was already designated as the lead

  • New passengers with different channel roles were imported

  • The system failed to recognize that existing passengers were valid lead candidates

As a result, the newly imported passenger would incorrectly become the lead passenger, overriding the existing lead assignment and potentially causing confusion in customer records and communications.

Solution

The passenger validation logic has been enhanced to properly evaluate all passengers—​both existing and newly imported—​when determining lead passenger assignments. The system now:

  1. Retrieves complete role information: When validating lead passengers during import operations, the system fetches channel role details for both incoming passengers and existing passengers on the itinerary

  2. Validates across all roles: The lead passenger eligibility check now considers the occupant types of all passengers, ensuring existing valid leads are preserved

  3. Maintains data integrity: The enhanced validation prevents incorrect lead reassignment when passengers with various channel roles are present

Impact

For Operations Teams:

  • Passenger imports will now correctly preserve existing lead passenger assignments

  • Lead passenger information will remain accurate when adding passengers to itineraries with multiple channel role types

  • Reduced need for manual correction of lead passenger assignments after bulk imports

For Sales and Customer Service:

  • Customer communications will consistently reference the correct lead passenger

  • Improved data accuracy for itineraries with diverse passenger configurations (e.g., drivers, captains, adults)

  • More reliable lead passenger information for booking confirmations and correspondence

For System Administrators:

  • Enhanced data quality for passenger records

  • Reduced support requests related to incorrect lead passenger assignments

  • Better handling of complex itinerary configurations with multiple role types

Technical Details

Ticket: Components Modified: Passenger trigger logic, Lead passenger validation Test Coverage: Added comprehensive test case covering multi-role scenarios with existing and new passengers

Validation

The fix has been validated with scenarios including:

  • Itineraries with existing TBD passengers as leads

  • Import of passengers with different channel roles (Driver, Captain, etc.)

  • Multiple existing passengers with various occupant types

  • Verification that only one lead passenger exists per itinerary after import operations

Passenger Allocation screen is missing Horizontal scroll when there are many passengers in an itinerary (KT-14102)

Fixed Passenger Allocation screen scroll

Kaptio Passenger Import API permission issue resulting in duplicates (KT-14103)

Fixed the issue with different permissions for creating and updating passengers via API import.

Operational itinerary status do not update to "Failed" if its parent job fails. (KT-14160)

Set recalculation status to failed on OI when the main transaction has failed during reevaluation

Unable to save travel dates in Price model (KT-14225)

Fix for an issue when user can’t save travel dates in Price model