D-47873 - Community - Scheduler Relaunch Error
Description
We have identified an issue where, for any category completed runs, whenever the relaunch is initiated, the application displays an error message. Please see the image below as reference.
Despite this, the application allows the normal process flow to continue after clicking the OK button. It appears that the code changes made in D-40358 may have introduced this issue.
Resolution Details
The fix for D-40358 addressed an issue where the retrieval of template parameters is always directed to the server. However, when relaunching a run, a temporary template named “temporary_template” is created locally and does not exist on the server. The solution is now to use cached parameters for relaunched runs to accommodate this temporary template scenario.
D-47051 - Community - Calendar in Pairing Report is Extended while Past Pairings are Loaded
Description
We resolved an issue where the calendar in the Pairing report is not extended correctly while loading past Pairings.
Example
In the UCA environment, on trunk 6 with the active period of August 2024, the report now properly loads pairing data from April 2024.
Resolution Details
To address this, the system has been updated to validate imported files by checking whether any Pairing starts before the beginning of the “Period.” If such a case is detected, an error message displays, and the file contents are ignored.
D-47593 - Community - Display Issue on Calendar
Description
We resolved an issue where on devices with smaller screen dimensions, the calendar in the ALC, and Training tabs does not display dates properly, with some dates hidden under the Pairing identifier field. Nonetheless, this fix ensures the calendar displays correctly across these tabs on smaller screens.
Resolution Details
To resolve this issue, we have re-written the weekdays and dates display using new alignment logic. This forces correct appearance regardless of screen width.
D-47719 - Community - Fix Analyze Reports Day/Date Display
Description
We resolved an issue where changes in D-47593 altered calendar date displays. This causes broken "report view" day displays in the bids analyze calendar, such as in the Show Pairing report.
Example
Resolution Details
To resolve this issue, we fixed the dates display to ensure they appear correctly.
D-46873 - Community - Hover Message is Covered by Report Data Layer in WebApp
Description
An issue where the Print button hover message is partially hidden by the Report section (only a small portion of the popup is visible) in WebApp is resolved. This occurs when the Report is prepared. Nevertheless, the full hover message now displays properly.
The issue is impacting Report in:
- Results page in Awards section
- Pairings page
- Training page
Resolution Details
The issue is caused by not correctly applying styles in CSS affecting layers on the WebApp. In addition, the tooltip is not visible due to the overflow: hidden style applied to a parent container. This issue causes the tooltip content that extends beyond the container to be clipped, while the overlapping records layer blocks the tooltip from view. This issue is now resolved.
D-47172 - Community - List Ordering Button Issue
Description
We resolved an issue where changing the sorting value required clicking the “Order” button twice to update the List order. The fix now automatically refreshes ordering when sorting value is changed, and sets increasing order immediately. Note: This issue is also apparent in the Short Calls list and reproduced in the Pairing list.
Resolution Details
This issue is now fixed by using the same set of sorting functionality for Pairings, Short Calls, and Training pages. The arrow direction now updates correctly when the sort field changes. In addition, the Sorting field and order direction are cached between pages (not between reloads), so when users move between Pairings and Bids, the sorting remains consistent until page reload.
D-46727 - Community - Mouseover Information for ‘Print’ Button is Wrongly Formatted
Description
We identified an issue where, in the WebApp Results tab, the mouseover text for the Print button is wrongly formatted, causing the letter 't' to appear on the next line (row).
Example
Resolution Details
We resolved this issue by applying CSS adjustments that fully display and center the "Print" button tooltip text. These improvements enhance usability and visual clarity of the “Print” button.
D-46725 - Community - Printout Is Cut Off When We Scroll Down the List Before Trigger Printing
Description
An issue is identified where printing the Awards or Reasons list after scrolling down, before printing, shows only part of the Awards or Reasons information on the WebApp UI. The printout gets cut off, missing information below the scroll.
Additionally, similar issues appear to affect other printing functions:
- Bids
- Toggled Calendar view:
Note: All printouts must be checked.
Resolution Details
To resolve this issue, we removed the scrollable behavior, specifically for printing. This change ensures the full content is properly printed without being cut off by scrolling.
D-47178 - Community - Training Patterns Analyzer for Bid Group and All Bids is Not Counting Matching Lines
Description
We corrected an issue in the Training Patterns Analyzer for Bid Group and all Bids where matching lines are not being counted. This fix addresses a problem similar to the one resolved for the Analyzer of a particular line in D-41960.
Example - When User bids for Training Patterns and uses Analyzer for Group or all Bids
Then, Matching Bid line or Filtered Pool do not display proper values
Resolution Details
We resolved this issue by modifying the selection process to automatically select the newly added Training Bid Line after clicking the Apply button.
D-47286 - Community - Report for Employees Sorted by Training Seniority Crashes the Server
Description
We identified an issue affecting all ALCs with trainings (e.g., DAL, ACA) where the Crew Report for Employees sorted by Training Seniority crashes the server.
When the "Generate Report" button is used, the server connection is lost, requiring a server restart to recover.
This issue is now resolved.
Appach logs /var/log/httpd/error_log for DAL and ACA are attached.[1] [2]
Resolution Details
We have resolved this issue by enhancing the sorting algorithm implementation to provide clear and unambiguous comparison rules required by std::sort in C++. This ensures that the All Employees report, sorted by training seniority, generates correctly without crashing.
D-47167 - UCA - Launch Run - Error
Description
We identified an issue caused by a faulty upgrade script (1.760) used to upgrade UCA from “Concurrent” to “ConsecutiveMixedLines.” The script updates RunSignatures only for the active period, not for any future prepared periods. When one of these incorrectly configured future periods becomes active, the error occurs. This issue affects both RHEL6 and RHEL8 systems. The fix ensures that RunSignatures are properly updated for all relevant periods, preventing the error during run launch.
Resolution Details
We resolved this issue by amending the upgrade script to include future prepared periods as well as the current active period. This ensures that all relevant periods are properly updated during the upgrade process.
D-47399 - 25.3 - Community - WebApp - Cancel Synchronization when Checkbox Unchecked - Screen Hangs
Description
We have discovered an issue where the cancel (X) button behavior on the synchronization screen is problematic if the “Automate On Startup” checkbox is unchecked.
After consultation during Refinement, we decided to block and gray-out the cancel (X) button when synchronization is in progress, whether auto(matic) or manual, and regardless of login status.
Note: If the X button is pressed on log in when no synchronization is occurring, it triggers a logout.
Resolution Details
We have resolved this issue by making the cancel (X) button inactive and grayed-out when synchronization is in progress, preventing cancellation. Additionally, if synchronization is canceled from the synchronization screen that appears on login, it properly logs out the user.
D-47351 - DAL - Awarding via Pairings Tab Works Differently for the Same Pairings List Depending on Filter or Selection Usage
Description
We have discovered an issue where on the Pairings tab, the Bidder is not able to add bid lines based on the entire content of a filter if the filter is created based on Pairing identifiers. This issue occurs only when the filter is created by Identifier and the “Enabled filter” option is turned ON.
Note: The problem does not exist for other types of filters.
The following message appears when the Award button is clicked, and the bid line is not added to the bid group.
a) Filter enabled and no selection
b) filter enabled and pairings selected
Simultaneously, when the Bidder disables the filter (Enabled filter is OFF), the same selected pairings are added to the bid group.
Also, we discovered that the “If Pairing-Numbers …” filter is excluded from adding bids. This occurs when two filters are applied, and one of them is the “If Pairing-Numbers …” filter:
Only the filter that is not "If Pairing-Numbers ..." is added to the bids.
Resolution Details
We resolved this issue by adding an additional variable with enhanced functionality to WebApp/js/controllers/pairingscontroller.js. This update enables users to add new ‘Pairing Number’ bid lines directly from the ‘Pairing’ tab into the ‘Pairing Bid Group’.
D-47707 - DAL - Warning Message Is Missing when Awarding from Short Calls Tab while Improper Bid Group or No Bid Group Is Selected
Description
We resolved an issue where a warning message is missing when adding bids from the Short Calls tab while an improper or no Bid Group is selected.
For Short Calls awarding from the Short Calls tab, there should be a similar message that exists for pairings when Pairings are awarded and a wrong or no Bid Group is selected on the Bids tab:
Resolution Details
This issue is resolved by fixing the logic that checks which bid group is selected. Now, if the selected bid group is a Pairing group or an UltraLongCall reserve bid group, the alert message properly shows.
D-46942 - DAL - Incorrect Indexation of Copied Bid Lines
Description
We resolved an issue where copied bid lines with Short Call do not update their indexation correctly in specific cases. The copied bid line retains the original bid line number even after changing the assigned bid group. This problem affects both single bid lines and groups of copied bid lines.
Resolution Details
This issue is now fixed by modifying the cloneBidLine function to assign the correct object structure and ensure each copy receives a unique bid line number. Previously, duplicated “Award Short Call” lines retained the same value as bidLineNumber, causing conflicts and unexpected behavior. With this update, each pasted line is treated as a separate entry, eliminating those issues.
D-47082 - DAL - Training Requirements Report Can Not Be Generated in Admin UI
Description
An issue where the Training Requirements report could not generate in the Admin UI is identified. The issue was initially found for DAL but is also reproduced on another airline with Training Reports (ACA). This issue is now resolved.
Resolution Details
We resolved an issue caused by wrongly defined conditions for handling DBConnection for Awards and TrainingGroup, which leads to database connection problems and prevents proper report generation. The changes implemented fix the DB connection at all levels, enabling reports to be generated correctly.
D-46509 - Community - Synchronization Hangs When There is No Refresh Before Logging to WebApp After Locking the Period in Admin UI
Description
We have discovered an issue where Synchronization hangs if there is no refresh before logging into the WebApp after locking the period in the Admin UI. This issue is now resolved.
Resolution Details
The issue is now resolved by changing the refreshment of AppConfig during the log in process to retrieve current information about the locked bidding period.
D-46858 - DAL - Item Text is Used in the Dropdown and Column of Daily Short Call
Description
We have updated the item text display in the dropdown and column of Daily Short Call to better represent the original story.
Resolution Details
We have resolved this issue by updating the text for the dropdown and the column on the Import screen as per the story.
D-46930 - DAL - The Daily Short Call Import Error Message for Length is Confusing
Description
An issue where the UI shows errors for length exceeding the expected values, including:
- ERROR Error at line #2: Expected Base String to be of length 3, found length to be 62
- ERROR Error at line #5: Expected Equipment String to be of length 3, found length to be 2
is identified and resolved.
Expected Results
Remove the latter “to be” as done in lines #14, #15, #22, and #23.
Resolution Details
This issue is now resolved. The error message is now clearer with the removal of “to be,” improving its readability and user comprehension.
D-46914 - DAL - The Daily Short Call Import Error Message Has No Details for Duplicated Identifiers
Description
We corrected an issue where the UI displays the error message: “An error has occurred: Error Occurred - Unable to process ‘Daily Short Call Item’ data: Import data rolled back,” however provides no details of the error.
Expected Results
The error details should include information about duplicated identifiers.
Resolution Details
We resolved this by adding a check to flag duplication of identifier and category. This ensures that any duplicated entries are detected, and the import process is stopped.
D-46912 - DAL - The Daily Short Call Import Error Message Ignores the Empty Value of the Count
Description
We resolved an issue where the Daily Short Call import error message ignores the empty value of the Count.
Expected Results
The Count field must not be empty as specified in story S-90037; an error message should display to prevent the import.
Actual Results
The import completed successfully without errors. The pairing data status displays as DSC/1, and the report shows a Count of 0.
Resolution Details
We have resolved this issue by ensuring that if the Count field is empty, the importer displays an error message as specified in the story spreadsheet. Additionally, records with a Count of 0 are not included towards the sum of DSCItems in the import screen columns.
D-46926 - DAL - The Daily Short Call Import Error Message Is Inaccurate Without Pointing Out the Expected Month and Year
Description
For DAL, we identified an issue where the UI shows the error message: “ERROR Error at line #1: End date on import file does not match the activated period end date. End date expected: 30 found: 30.”
Expected Results
The error details should not display the expected values.
Resolution Details
We resolved this issue by enhancing the system to correctly display the full date whenever an invalid date is used in a record's start or end date fields.
D-46952 - DAL - The Daily Short Call Import Error Message Only Catches Invalid Hours, Not Both Hours and Minutes in One Line
Description
We identified an issue regarding the Daily Short Call import error message only catches invalid hours, not both hours and minutes in one line. The UI shows errors such as:
- ERROR Error at line #3: Expected Item's start time hour to be numeric, found: @0
- ERROR Error at line #4: Expected Item's start time hour to be numeric, found: 1A
- ERROR Error at line #5: Expected Item's start time minute to be numeric, found: 0A
- ERROR Error at line #6: Expected Item's start time minute to be numeric, found: !0
Expected Results
The hours and minutes display on the same line, requiring the Admin to determine the source of the error.
Resolution Details
To address this issue, we enhanced the error handling so that instead of showing separate errors for invalid hour or minute formats, the error message now clearly displays the combined time (Hour and Minute) when non-numeric values are detected.
D-46903 - DAL - The Daily Short Call Import Error Message says “Internal Error” However No Details Provided
Description
For DAL, we corrected an issue where an error message shows “An error has occurred: Error Occurred - Internal error: exception thrown on Import Data Job: Import data rolled back
Please clear the error.”. This issue is now resolved.
Expected Results
A specific error message should be provided instead of a generic “internal error” notification.
Resolution Details
This issue has been fixed by swapping the position and error message strings in the errMsg function (previously, errMsg would output a position string as upperCase even when the character was not A/B). The importer now raises an error with an appropriate message if the length of the date string is not exactly 7 characters. Similarly, the importer raises an error with an appropriate message if the time string is not exactly 4 characters long.
D-46928 - DAL - The Daily Short Call Import Ignores the Header (Record Type 0)
Description
We fixed an issue where the Daily Short Call import ignored the header (Record Type 0). The import now correctly fails if the header is blank, preventing the file from importing.
Resolution Details
We resolved this issue by implementing error handling that stops the import process and displays an error if:
- the import file’s first line or first lines are blank, or
- the file does not begin with Record Type 0.
D-47652 - FLE - The Pairings With the Same Number (on Different Dates) are Not Rejected by Import
Description
We corrected an issue where pairings with the same number are displaying incorrectly in the system. To ensure data accuracy and prevent these problems from recurring, we updated the import process to be more secure. The system now rejects any pairing file import that contains duplicate pairing numbers within the same period, ensuring each pairing number is unique within its bid period.
Resolution Details
We resolved this issue by enhancing the import process to prevent data inconsistencies. If two pairings with the same pairing number but different data are detected within the same Period, the import fails and displays an error message indicating that importing pairings with duplicate numbers and differing data is not allowed. Pairing hash (BASE-PAIRING_NUMBER) needs to be unique in the current Period. This update ensures that pairing numbers remain unique within each bid period.
D-47303 - VXP - Two Green Options Uninitialized
Description
For VXP, we resolved an issue where two configuration settings for Green pairings were not correctly set, potentially causing unpredictable behavior and errors during the scheduling process.
Resolution Details
We resolved this issue by updating vxp/PbsSettings.xml to set the correct values for VXP. In addition, we updated the code to initialize these values to false before they are overwritten by any configured settings.
D-47465 - ASA/DAL/Community - Pairing Filter add Bids Mode - Wrong Syntax for IF/IF NOT Duty on Day of Week
Description
An issue is identified where the “Duty On IF/IF NOT > Days of Week” condition displays an incorrect message as “undefined” in the award pop-up. This also causes the bid to be updated incorrectly with “undefined” values (for example, selecting Friday displays as “undefined”).
There appears to be an issue affecting all IF/IF NOT Any and Every conditions. Please see the images below.
IF Examples:
Instead of “If Any Duty On Friday” it displays “undefined”
Also, when added to the bid, it also displays “undefined”
IF NOT ANY Examples:
IF/IF NOT EVERY Example:
Resolution Details
We were missing information about the days of the week during the award process. An undefined variable was referenced, which causes issues in both the alert window and the bid tab. We resolved this issue by correcting the variable mapping and ensuring proper handling of day-of-week information during the award process.
D-47050 - ASAP - Email Imports “Wiping out” Statuses
Description
We resolved an issue where importing an email address after the I5 file causes the I3 file to not correctly display a crew attribute of PPLH. This is now corrected to ensure the I3 file displays the crew attribute that matches the proper status from the I5 file.
Resolution Details
We fixed this issue by addressing a problem where importing an email address after loading the I5 file causes the I3 file to display the crewAttribute as PPLH instead of the correct status from the I5. While the StatusType is set correctly during the I5 import, it is being cleared after the email import.
The root cause is due to the use of std::string instead of std::optional<std::string>. With std::string, an empty value is treated as valid and overwrites the existing status.
After the fix, email imports no longer clear the previously set status, and the import process now works as expected.
D-47092 - ASAP - Wrong Status in I3 When Changed from Ineligible to Eligible, and Back to Ineligible
Description
We resolved an issue with how a Pilot's status code is handled when their bidding eligibility is manually changed. The issue occurs in a specific sequence: when a pilot is set to ineligible, their status is correctly exported from the I5 file to the I3 file. If their eligibility is then manually updated to eligible in the UI, the I3 file correctly reflects the PPLH status. However, when changed back to ineligible, the I3 file incorrectly retains the PPLH status instead of reverting to the original status from the I5 file.
Resolution Details
We fixed this issue by updating the code to remove the logic that clears a Pilot's status when the user is set to eligible.
D-47020 - Community - Award Stat Day Bids With Awards Showing Two “Awarded…Running Total” Lines
Description
We resolved a minor display issue with the Vacation Opt-In Virtual Credit running totals in the Reasons Report.
What Is Happening
In a pairing bid group, if a bidder is awarded a Stat Day bid, the Reasons Report sometimes displays two identical “running total” lines for the awarded credit. While the final credit calculation is not affected, the duplicate entries can cause confusion. See image below as reference.
Resolution Details
We fixed this issue with a code change to the ReasonsReport.cpp.
D-47018 - ASAP - Bug Causing Vacation Reduced Credit Window to be Wrongly Used When Limit is Reached
Description
We identified an issue where a single line of code is accidentally lost during a previous merge, however, restoring it resolves the issue.
The original update that introduced the Max Vacation Reduced Credit Honoured limit did not merge properly into the current version. As a result, the system continues to use the Reduced Credit window even after the limit is reached.
By re-applying the missing line of code in TripBidGroup.cpp, this ensures the system correctly reverts to the standard bidding window once a Bidder’s Vacation Reduced Credit limit is met.
Resolution Details
To address this issue, we updated the code.
Note: This code was originally implemented and tested correctly within the initial story, however during the mega-merge from develop to developunified, a small portion was not merged properly.
D-40358 - Community - Bugs in Run Template Max Stack Height By Qualification and Disallow Language Credit Unstacking Selected Languages
Description
We fixed an issue in the run template that affects how certain configurations display after being edited. The issue occurs when removing some, but not all, items from the "Max Stack Height by Qualification" and "Disallow Language Credit Unstacking" lists. Although the system correctly saves these changes to the database, the screen does not refresh properly, causing the template to continue showing the old, unedited lists until you either log out and back in or manually refresh the page. Nevertheless, with this fix, the run template now instantly and accurately reflects any changes made to these lists, ensuring a smoother and more consistent user experience.
Resolution Details
To resolve this issue, we updated the Admin UI template code to always retrieve template parameters directly from the server. Previously, the template did not correctly restore parameter values cached in the browser, even though the parameters were properly persisted on the server.
D-46853 - Community - Locked Function
Description
We fixed an issue that prevents users from logging in when a period is locked.
Resolution Details
To resolve this issue, we fixed the constant loading problem that occurs when translations are not downloaded. In addition, for SSO mode, we implemented a proper log out process when a period is locked.
D-41960 - Community Analyzer - Training - Nothing Showing as Matching Any Bid Line
Description
An issue where the Analyzer is not showing all proper results is now resolved.
Resolution Details
To resolve this issue, we added a timeout line in WebApp/js/controllers/bidscontroller.js to ensure that lines are selected and updated correctly. Previously, Angular.js execution was triggered too early—before the view had finished rendering. Nevertheless, this update guarantees that operations now act in a stable and fully initialized state.
D-47290 - COMMUNITY - Combined Report from Completed Run Can Not Be Generated
Description
We resolved an issue where an error message appears a few seconds after an Admin attempts to generate a Combined Report from a run.
Resolution Details
This issue is now fixed by correcting how reports are added to the Combined Report. This issue occurred because of the improper inclusion of certain reports that should have been omitted when no report existed for ALC. Nonetheless, the fix implements the proper logic for adding reports, and the Combined Report now generates correctly.
D-47388 - Community/HAL - Reduced Credit Windows In Wrong Order
Description
Improved Display for Credit Window Parameters
We identified an issue where the Credit Reduced Block options do not always display in a logical order. Previously, the options did not always show in a logical order. We have resolved this issue by completing a minor update to the interface so that these options now appear correctly from minimum to maximum.
The new order is:
- Min Credit Reduced Block
- Mid Credit Reduced Block (if configured)
- Max Credit Reduced Block
This update to the issue makes the interface more intuitive and easier to use when configuring these parameters.
Resolution Details
We resolved this issue by analyzing the corresponding code in
CLASS/WebArch/html/js/class/widgets/credit_window_parameters.js.
The fix involves swapping the code blocks for “Min Credit Reduced Block" and "Max Credit Reduced Block" to ensure the correct display order:
- Min Credit Reduced Block
- Mid Credit Reduced Block (if configured)
- Max Credit Reduced Block
Root Case: The incorrect ordering of the two blocks of code.
Validation Steps:
Example #1: Customer Not Configured for Mid Credit
Given HAL Admin
When Relaunch a Run
Then the Credit Windows will show the following in order
- Min Credit Reduced Block
- Max Credit Reduced Block
Example #2: Customer Configured for Mid Credit
Given DAL Admin
When Relaunch a Run
Then the Credit Windows will show the following in order
- Min Credit Reduced Block
- Mid Credit Reduced Block
- Max Credit Reduced Block
D-46949 - COMMUNITY - Crew Calendar Tab: Dates/Days Not Centered
Description
We have resolved an issue where, starting in version 25.1, the date and days of the week on the “Calendar” tab of the Crew Portal are not centered—a change from previous versions. This issue is reproducible in version 25.3 and trunk.
Resolution Details
We fixed the issue by creating a new CSS class (.calendarDateCell) in WebApp/css/app.css and adding it to the HTML. This class centers the content of the date cells in the “Calendar” tab, ensuring that all dates are now properly aligned to the center.
D-47536 - DAL/ASA/Community - Pairings Tab > Filter for Duty on > IF Not, Every > Date List
Description
We have resolved an issue with the Pairings Tab filter that produces incorrect results when using the “Duty On > If Not, Every > Date List” combination. This issue occurs because the filter was not correctly identifying and excluding pairings with a duty on specific dates from the list. As a result, pairings that should be filtered out are still displaying, leading to inaccurate results.
Example
When searching for pairings that do not have a duty on a particular date, the system incorrectly includes pairings that are operating on that date in the results.
Resolution Details
We have fixed this issue by correcting the logic used when the “Duty On” filter is applied with the “IF NOT EVERY” condition. Previously, the function responsible for filtering pairings returned incorrect results because the loop that determined whether a pairing matched was run more times than intended. This causes the matching variable to be set incorrectly, making the function treat some pairings as non-matching even when they do match. In effect, the filter behaved as though it were using “IF EVERY” instead of “IF NOT EVERY.”
Note: With the changes applied, the filter now correctly handles the “IF NOT EVERY” condition across all tested scenarios.
D-47655 - NKS - Duplicate “Stack Groups In Force Order” on Unstacking Report
Description
We discovered an issue where the Unstacking Report displayed duplicate entries in the “Stack Groups In Force Order” table, even though no new stacks are triggered. This occurs when a pass diverged on a person but the calculated Stack Groups remained identical to the previous ones.
Resolution Details
We fixed the issue by updating the code so that Stack Groups are recalculated before processing each person only when either:
- a new stack is triggered, or
- the pass is diverged from the previous pass on that person.
D-47047 - SSO Community - Internal Server Error When SSO is Enabled in Combination to redirect_to_webapp
Description
We corrected an issue that prevents users with Single Sign-On (SSO) enabled from logging in to the new Bidder interface.
Previously, attempting to log in caused an internal server error due to a problem in how the application handled redirects to the new interface when SSO is active. With this fix, users can now log in and access the new Bidder interface without errors.
Resolution Details
We fixed this issue by correcting an incorrect function call that caused the “Internal Server Error”:
Undefined subroutine &NAV::Class::GetClearSSOCookie called at /navtech/NWS/lib_perl/NAV/Class.pm line 2253. The function is now NAV::Class::GetClearCookie instead of NAV::Class::GetClearSSOCookie.
D-47070 - JBU - Export File shows RES Instead of RSV
Description
For JBU, we identified an issue where the Export File displays “RES” instead of “RSV.” The value should correctly show as “RSV.”
Resolution Details
We fixed this issue by making a global update that replaces all instances of “RES” with “RSV.”
D-46545 - JBU - TOPS - Integrated Imports - Server Error (Security Certificate)
Description
We discovered an issue where any change made to NOC integrated imports (e.g., D-46258) also affects TOPS integrated imports. Historically, updates to NOC imports have had an unintended impact on TOPS imports.
Resolution Details
We corrected this issue by ensuring the server provides the full certificate chain. Previously, the server only supplied its own certificate without the required intermediate certificates, which causes verification failures because the client does not have the complete chain of trust.
The resolved this issue by adding the necessary root and intermediate certificates to complete the full chain.
After this update, the connection is now established successfully, and data requests from the server proceed as expected.
D-47006 - Community - Memory Leak in Scheduler Training Runs
Description
We resolved a memory leak in the Scheduler that occurs during Training runs. The issue is traced to the TrainingAllocator::SetupPersonBidInfo function, where memory allocated for the pMatching variable during CreateComboMatching is not being properly released. Over time, this causes the Scheduler to consume excessive memory.
Resolution Details
We fixed this issue by updating the code to correctly delete the pMatching variable once it is no longer needed, thus preventing the memory leak and ensuring the Scheduler operates efficiently.
D-47745 - QXE - Historical File Loading Issue
Description
We resolved an issue where Horizon Airlines is not able to load their Historical file, which is causing problems on their end. This issue is now resolved.
Resolution Details
We fixed this issue with a code change by reverting the SCX-specific update for QXE. The SCX fix is applied to other ALCs, since SCX is running on a newer version of AIMS.
D-47249 - COMMUNITY FOR NOC & PBS users - REVERT - VXP Historical Pairing Error
Description
For VXP, we identified an issue with the import of Historical Pairings and have reverted the change that causes it. Previously, if a pairing’s Start time fell in the next bid period (e.g., bid period Z) however the local time was in the previous period, the system fails to import the pairing correctly. This issue was especially problematic for Training Pairings, which can span multiple periods.
Resolution Details
By reverting the previous fix, the system now correctly recognizes and imports these Historical Pairings, ensuring no data is missed.
Note: This reversion applies only to the POE file and does not affect normal operations.
D-46866 - SCX - Incorrect Per Diem
Description
We have resolved an issue related to loading the CrewPlan file into UAT with version 25.1 installed.
Example
Pairing M0C57/24 should display a per diem value of $261.07, and the file itself contains the correct value. The issue is due to how the system handles columns 601 and 602, which represent the cents portion of the value. In this case, “07” is the value in those two columns.
Resolution Details
We resolved this issue by addressing a bug in the code. Internally, the system correctly handles the per diem value as 261.07. However, when generating the report, dollars and cents are printed separately, and if the cents value is a single digit, the leading zero is omitted, causing the value to display incorrectly. This issue is now resolved.
D-46913 - SCX - Conversion Issue for Trip Start date of 01JUN UTC to 31MAY Local
Description
We have identified and resolved an issue with the Absence file load for the Jun24 period in PROD. When the file is processed, the system fails to correctly convert the Carry In Duty from UTC to the correct local base time Start date.
Example: Snippet of the absence data file
The trips begins on 5/31/24 and 6/1/24 UTC which should be converted to start on 5/30/24 and 5/31/24 local time, respectively. Using trip M0404 as an example, its Start date was 6/1/24 at 01:10 UTC, which converts to 5/31/24 at 20:10 Central in MSP. While the system correctly converts the time from UTC to local, it does not output the correct date.
Here's the output from NAVBLUE:
Note: The highlighted areas are the UTC start date and time.
Resolution Details
We fixed this issue by converting the pairing start date from UTC to the correct local time and using the local start date instead.
D-47049 - SCX - WebApp - Calendar Download Export Issue
Description
We discovered an issue where clicking the “Download PBS Schedule” button generated an exported file without the proper .ics extension. As a result, users receive the file as plain text and have to manually rename it with “.ics” before importing it into their calendars. However, the data is imported successfully once the file is renamed. In addition, the file is not correctly downloaded with the name “Unknown” instead of following the expected naming convention, “PBS Schedule,” which adds to user confusion.
Resolution Details
We have resolved this issue by updating the download procedure in accordance with the ICS documentation. The process now properly sets the file type to ‘text/calendar,’ ensuring the calendar file is recognized and downloaded correctly.
D-46821 - ASA,FFT, MXY, SCX - Time Off Before/After Wrongly Configured with If Not
Description
We discovered a configuration issue with the Award Pairings bid property “If Time Off Before/After” for the ASA, FFT, MXY, and SCX customers. The "If Not" option for this property is not correctly configured, even though the Scheduler does not support that functionality. As a result, when Bidders select “If Not Time Off Before/After,” the “Not” condition is ignored, and the bid is treated the same as “If Time Off Before/After.” This configuration issue is now resolved.
Resolution Details
We fixed this issue by updating the configuration for the affected ALCs to remove the "If Not" option from the Award Pairings “Time Off Before/After” property. In addition, we also updated the XSD file so that any future attempts to add the “Not” option in [ALC]/CategoryOptions.xml triggers a scons error, preventing similar issues from occurring.
D-46983 - ASAP - Vacation Opt In Virtual Credit Counting Multiple Times Towards Running Total
Description
For ASAP, we identified an issue where the “Virtual Credit” is being counted multiple times towards the “Running Total,” resulting in incorrect calculations.
Resolution Details
We resolved this issue by updating the report generation code to ensure the Vacation Opt-in Virtual Credit is added to the running total only once, within the used Bid Group. The “Running Total” line now shows exclusively under that bid in the used Bid Group.
D-48071 - Community - Unable to Generate Combined Run Report
Description
We resolved an issue where a bug is preventing combined Run Reports from being generated for customers other than DAL. This issue occurs because the system incorrectly attempts to use a report template file configured specifically for DAL, thus causing report generation to fail for all other customers.
Nevertheless, the logic has been updated to reference the correct, universally available report template, ensuring Combined Run Reports are now generated successfully for all customers.
Resolution Details
We solved this issue with a code change by adding a check to verify whether Short Call is enabled for the customer when generating the Combined Run Report.
D-47904 - Community - Analyzer Lists Improper Number of Matching Bid Lines
Description
We identified an issue where the Analyzer displays an incorrect number of matching bid lines. The problem is linked to using the Training page to create bid lines that are later added in the Bids page. See below image for reference.
When bid lines are created directly in the Bids page without first using the Training page, the issue does not occur.
In addition, if bid lines with display values that are not correct are submitted and the page is reloaded, the Analyzer then shows the correct number of matching Training bid lines.
Resolution Details
This issue is fixed by removing the use of the Training filter (configured in the Training page) from both the Bids page and the Training tab. This is because the filter does not correctly exclude training entries in the Bids page when using the Analyzer, which it should not do.
D-48716 - Community - Bid Group - Set Condition (Without Set Precedence) Can Not be Inserted Above Prefer Off or Avoid Line
Description
We resolved an issue concerning using a Bid Group, the user should have the ability to insert a Set Condition (without set precedence) above a Prefer Off or Avoid line.
Note: It is already possible to move a Set Condition above Prefer Off or Avoid by using the Up/Down arrows.
Resolution Details
We fixed the issue by adding an index check for Prefer Off and Avoid bid lines (while respecting Set Condition) in the function that determines the expected Bid line position.
D-48534 - Community - Ordering Problems Related to Bid Lines
Description
We released a new update that includes several important fixes to the Bidding System. These changes address issues related to ensuring a smoother and more reliable bidding experience.
Fixes to the Training Tab
We fixed an issue that prevents bid submissions from the Training tab. Previously, users could accidentally delete a system-generated bid line for a Training Award, which blocks the ability to submit bids. The system now prevents deletion of these required lines, ensuring bids can always be submitted successfully.
Improvements to “Prefer Off” Bids
We corrected an issue that affects “Prefer Off” bids. Previously, the system mishandled cases where a “Prefer Off” bid is placed between two Short Call periods, which could cause errors. With this fix, all “Prefer Off” bids are now processed correctly and consistently.
Resolution Details
The issue is resolved by enforcing Bid line precedence when adding, deleting, or copy/pasting Bid Lines, including cases that involve Short Call.
D-48728 - Community Reserve Bid Group - “Prefer Off” Line Can Be Inserted Above Set Condition with Precedence 2 (Forced to Extreme Top)
Description
We discovered an issue with the Set Condition “Max Above” with precedence 2 (forced to the extreme top) remaining at the top of the Reserve Bid Group when a “Prefer Off” line is inserted using the Insert Above button.
Resolution Details
We resolved this issue by adding respecting precedence for every Bid Line in the function that determines the expected index for inserting a new Bid Line.
D-48670 - Community Reserve Bid Group - Set Condition “Max Above” with Precedence 2 (Forced to Extreme Top) is Not Added on Top When “Prefer Off” is First Line
Description
We corrected an issue where the Set Condition “Max Above” with precedence 2 (forced to the extreme top) does not appear at the top when “Prefer Off” is the first line. After moving it to the top, the arrows become disabled, preventing it from being moved down and also blocking “Prefer Off” from being moved back above the Set Condition.
Note: Set Conditions may have different precedence values and behaviors depending on the ALC. When in doubt, the logic in the code should be reviewed with development. For DAL specifically, the precedence value is updated to 3.
Resolution Details
We resolved this issue by removing the faulty logic that places a new bid line with a set precedence value (such as “Set Condition Max Above,” but also applicable to other bid lines with precedence) below a “Prefer Off” line. The system now assigns the correct position for newly inserted or pasted bid lines based on precedence first, and only continues searching for placement after precedence is checked.
D-48672 - Community - Reserve Bid Group - Set Condition Without Set Precedence
is Going on the Bottom of the Reserve
Bid Group
Description
We identified an issue where a Set Condition without a defined precedence is placed at the bottom of the Reserve Bid Group along with Award Reserve lines, which also appear to lack a defined precedence.
Example
Based on the configuration file, Consecutive Days Off In a Row does not have a set precedence:
Resolution Details
To address this issue, we ensured that if the precedence of the added line matches already existing lines, the system uses the currently selected line together with the insert above/below state to properly locate the place to add/insert.
D-48661 Community Reserve Bid Group lines ordering issues
Description
We resolved several issues with the ordering of Bid Lines in the Reserve Bid Group to make the bidding process more flexible and intuitive.
Resolution Details
We resolved this issue by ensuring that a new bid line is inserted above the selected bid line. If the new line has no set precedence or shares the same precedence as already existing lines, it is allowed to be inserted above.
When adding a new line, we remove the logic that checks for a “Prefer Off” line, since this causes the new line to be placed in the middle instead of at the end.
D-48305 - Community - Running Out of Database Connections on Shared Servers
Description
We corrected an issue where the system manages database connections inefficiently, causing a large number of inactive “sleeping” connections. Currently, PBS pools up to 1000 connections for each application (UI, ClassBid, Scheduler) per customer (ALC), which leads to unnecessary overhead and degraded performance. This issue occurs because the system does not limit the number of active connections per application instance. We fixed this issue by introducing a new configuration parameter that restricts the number of active connections, preventing the creation of unused connections and improving overall performance.
Resolution Details
We resolved this issue by adding a new parameter, MAX_DB_CONN, to /navtech/parm/NAVNWSParams.xml. This parameter defines the maximum database connection pool size and can be configured globally or per ALC. If not specified, the default value is 1000.
D-48025 - Community/ASA - Bid Analyzer Filtering Out Things Due to Specific Lines That Do Not Match the Criteria
Description
We identified an issue where the Bid Analyzer filters results incorrectly. It displays the correct matched pairings but marks them as filtered out due to line 2 of landing in SEA, even though the pairing clearly does not land in SEA.
Resolution Details
We resolved this issue by fixing the value comparisons by not parsing string values to float in the function invoked when applying filters in Pairings and Trainings.
This applies to:
- Filters with the “Exactly =” comparison option (e.g., Average Daily Block Time, Average Daily Credit, Carry Out, Deadhead Legs)
- Filters without a comparison option (e.g., Redeyes, Landings In, Deadhead Day)
D-48068 - JBU- CrewPlan Pairing Import Issue
Description
For JBU, we identified an issue with importing CrewPlan Pairing files. Coding changes in S-94416 introduced a problem when checking the “Scheduled Layover Time in Minutes” field (columns 52–56) for all Duty Break Records (Type 3). JBU does not populate this field for Duty Break Records when no layover exists, which causes the import to fail.
Resolution Details
We fixed this issue by preventing the system from attempting to parse the layover field when it is blank, ensuring no error is reported and the import completes successfully.
D-48237 - 25.5 POE - Bid Analyzer Table Does Not Display Returned Pairings, Also Previous Filtered Pairings Are Empty in Pairings Tab – When Toggling Between Bids Tab and Pairings Tab
Description
We resolved an issue where, when toggling between the Bids tab and the Pairings tab, the Bid Analyzer table does not display returned pairings, and previously filtered pairings appear empty in the Pairings tab.
Example:
Resolution Details
We fixed this issue by correcting how the date range filter is applied in the Pairings (and Training/Short Call) tab. Previously, when combined with time, the filter lost the time portion after switching tabs. For example, instead of correctly checking the range 01/01/2025 00:00 – 01/01/2025 23:59, it only checked 01/01/2025 00:00 – 01/01/2025 00:00, causing items to not be correctly filtered out since only exact matches were included. This is now resolved.
Additionally:
- The Analyzer in the Bids tab was not correctly using the same filter as the Pairings tab; it no longer does so, as intended.
- The selected bid group in the Bids page was previously de-selected after changing pages, causing the Analyzer to appear blank when returning. The selection is now preserved.
D-48250 - ASA - Not Correctly Displaying Pairing That Checks In on One Date but Departs on Another (Analyzer & Bids Tab)
Description
We resolved an issue where pairings are not correctly displayed when they checked in on one date but departed on another in the Analyzer and Bids tabs.
Examples
In Pairings Tab:
- Select Depart on April 7
- Select check in after 2300 on April 7
- Apply
Note: This should NOT produce a result.
In Pairings Tab:
- Select Depart on April 8
- Select check in after 2300 on April 7
- Apply
Note: This should produce a result.
Resolution Details
The solution is to avoid calling the function responsible for retrieving the effective date twice. In the previous implementation, making two calls caused pairings with different effective and initial dates (for example, a pairing with a check-in time of 01.01 at 23:40 and a departure time of 02.01 at 00:30) to shift incorrectly twice, resulting in the date changing from 01.01 to 03.01 in this example.
D-48219 - ASAP - Bid Analyzer Not Adding Pairings to Potential Awards and Total Potential Awards
Description
We resolved an issue where matching pairings display correctly however do not appear in Potential Awards, even when requested on the first line.
Resolution Details
We fixed the issue by removing an unnecessary, likely copy‑pasted, not-needed if statement. With this correction, pairings are now added correctly to both Added and Total Potential Awards.
D-48125 - Community (ASA/ASAP) - Adding “Prefer Off” - Ordering Issue
Description
We identified an issue where adding a Prefer Off preference to a bid group does not insert it in the correct order and instead always places it at the top of the group.
Example
A “Prefer Off” preference added on line 3 using the “Insert Below” option from an Avoid Pairing
bid preference (currently line 8, previously line 7 before “Prefer Off” was applied) is not
correctly positioned.
Resolution Details
We resolved this issue by correcting the indexation logic. The issue is caused by improper indexing, which is now addressed through new functions (getFirstInsertIndex, getLastInsertIndex) implemented in WebApp/js/services/bidsservice.js. These functions provide a safer approach to Bid Line indexation, ensuring that the “Prefer Off” line is now added in the appropriate order.
D-47906 - Community (Reported by ASA/P) - Editing “Prefer Off and AVOID” JUMPS the Added Order of Award
Description
We identified and resolved an issue where editing an existing negative bid, such as “Prefer Off” or Avoid, causes the preference to improperly moves above an Award Statement.
Example
- When adding an Avoid line into line 12 and edited line 9 to a range of 1-2 days, the “Prefer Off” line incorrectly moves above the edited Award Statement.
- When later editing line 11 to add ABQ as a landing requirement, the Avoid preference on line 12 again moved above line 11.
Resolution Details
The provided changes in the code related for indexation of bidlines (ClassBid: bidsservice.js) corrected the unexpected moving bidlines after the edition. Moreover, changes provided that "Prefer off" no longer changes its position after pasting.
We fixed this issue by updating the Bid Line indexation logic in ClassBid: bidsservice.js. These changes corrected the unexpected repositioning of Bid Lines after edits and ensured that “Prefer Off” no longer changes position when pasted.
D-48252 JBU - Inflight CM's Can Not Submit RCL Reserve Bid Groups
Description
We identified an issue where the Award Reserve function for the RCL Reserve Bid Group is not working, as all submission attempts fail regardless of the method used.
Resolution Details
We resolve this issue by implementing the following approach:
- If there is more than one bidder-entered Award Reserve (without Reduced Credit Line), all except the last must include Max Above.
- Similarly, if there is more than one bidder-entered Award Reserve (Reduced Credit Line), all except the last must include Max Above.
D-46618 - SCX - Job146 Export
Description
We resolved an issue with the Job146 Export by making the following updates to align with SCX’s requirements for their go-live:
Time and Date
- All exported times and dates are now in UTC instead of local time to ensure consistency with the AIMS system and prevent discrepancies in trip, pairing, and activity logging.
Activity Codes and Timestamps
The system now handles activity codes and their corresponding timestamps as follows:
- The activity code “OFF.” is updated to “OFF” (removing the period) to prevent import errors in AIMS.
- The time column for “OFF”, “OFFG”, and “VCN” activity codes is now null, with no times included. This prevents misinterpretation of shortened "OFF" periods and simplifies
the data.
Nevertheless, these changes ensure that the Job 146 export file is correctly formatted and successfully imported into the AIMS system.
Resolution Details
We fixed this issue by updating the SCX export logic to address data discrepancies. All dates and times for Pairings, Absences, and Reserve Blocks are now converted to and exported in UTC instead of local station time.
Additionally, “OFF” days following an activity that ends after midnight are now correctly formatted as “OFF” (instead of “OFF.”), and the unnecessary Start and End time values for these entries are removed to comply with downstream system requirements.
D-48208 SCX- Enable Add Bid Mode Error
Description
We have fixed an issue that was preventing Bidders from successfully validating their Pairing bids.
The system was incorrectly creating bid lines using a property called PairingNumberStartOnDates. This was an issue because your configuration only supports PairingNumberCheckInDates. As a result, the Bid Lines would fail validation and could not be submitted.
What is fixed?
We have updated the system with new logic to prevent this from happening. It now correctly creates Bid Lines using only the PairingNumberCheckInDates property, ensuring that the user’s bids pass validation and can be processed as intended.
Resolution Details
We resolved this issue by addressing a configuration mismatch for SCX. The configuration defined the PairingNumberCheckInDates property however did not include PairingNumberStartOnDates. The issue occurs because the WebApp generated a Bid Line with PairingNumberStartOnDates, which fails during validation. New logic is now added to prevent this from happening.