N-PBS 25.3 Enhancements

Modified on: Fri, 6 Jun, 2025 at 5:29 PM

S-87706 - Community - Implement Full SAML 2.0 Login/Logout Process in

Admin UI

We implemented a symmetrical SAML 2.0 login/logout process for the N-PBS application, replacing the previous asymmetrical approach that used SAML 2.0 for login, and OAuth 2.0 for logout. This change ensures consistency in the authentication flow and reduces the configuration complexity for each customer Identity Provider (IDP).

Previously, login was handled via the SAML 2.0 protocol using federation metadata provided by the customer’s IDP, while logout relied on a manually configured OAuth 2.0 logout URL, specific to each customer. This inconsistency introduced potential issues as the logout URL had to be guessed due to specific customer parameters.

This enhancement introduces the use of SAML 2.0 for both login and logout, implemented through the Admin UI.

Note: Although SAML 2.0 logout functionality existed within PBS, it had not been invoked in the workflow. This enhancement includes verification and proper integration of the SAML 2.0 logout method at the appropriate point (stage) in the logout process. Also, it removes the need to configure the logout redirect URL for SSO customers.

Acceptance Criteria:

GIVEN - the DevTools are open in Chrome on the network trace tab

WHEN - a Bidder logs into the PBS Admin UI using SSO

THEN -

a SAML 2.0 login request appears on the network trace and is sent to the IDP
the PBS Admin UI receives and processes the response
the user is logged into both SSO and the PBS Admin UI.

GIVEN - the DevTools are open in Chrome on the network trace tab

WHEN - a Bidder logged into the PBS Admin UI using SSO clicks the logout button

THEN -

a SAML 2.0 logout request appears on the network trace and is sent to the IDP
the PBS WebApp receives and processes the response
the user is logged out of both SSO and the PBS Admin UI.

S-87705 - Community - Implement full SAML 2.0 Login/Logout Process in WebApp

We are implementing a symmetrical SAML 2.0 process for both login and logout in the N-PBS application, replacing the current asymmetrical approach. Currently, login uses the SAML 2.0 protocol and is configured using the federation metadata provided by the customer’s IDP. On the other hand, logout uses an OAuth 2.0 logout URL set in PBS parameters for each customer IDP. This inconsistency not only complicates configuration—requiring the logout URL to be guessed and customized for each customer IDP—but also introduces potential issues and hazards.

This enhancement introduces the use of SAML 2.0 for both login and logout processes in the WebApp.

Note: Although SAML 2.0 logout functionality existed within PBS, it had not been used in the workflow. This enhancement includes verification and proper integration of the SAML 2.0 logout method at the appropriate point (stage) in the logout process. Also, it removes the need to configure the logout redirect URL for SSO customers.

This enhancement eliminates the need to configure a logout redirect URL for SSO customers, thus streamlining setup and reducing the risk of error in configuration.

Acceptance Criteria:

GIVEN - the DevTools are open in Chrome on the network trace tab

WHEN - a Bidder logs into the PBS WebApp using SSO

THEN -

a SAML 2.0 login request appears on the network trace and is sent to the IDP
the PBS WebApp receives and processes the response
the user is logged into both SSO and the PBS WebApp.

GIVEN - the DevTools are open in Chrome on the network trace tab

WHEN - a Bidder logged into the PBS WebApp using SSO clicks the logout button

THEN -

a SAML 2.0 logout request appears on the network trace and is sent to the IDP
the PBS WebApp receives and processes the response
the user is logged out of both SSO and the PBS WebApp.

S-82955 - Community - Change Cache Clearing Message

We improved the cache clearing notification in N-PBS to provide clearer information to users during version updates. This ensures users are fully informed about what data is affected during an update. Previously, the message did not specify the impact on cached data and saved bids.

The updated message now reads:
"There has been a N-PBS Version Change: N-PBS will be updated and all of the cached data including saved bids will be deleted. Submitted bids will NOT be impacted."

Acceptance Criteria:

GIVEN - a Bidder

WHEN - logging in to the WebApp after a Version Change

THEN - updated message displays to Bidder.

S-92714 - Community - Default to Scroll Behavior on List Views

We enhanced the functionality of List Views for Rule Editor, Logs, etc. by updating the default scroll behavior. Now, by default the checkbox is “unchecked”, which allows users to scroll freely anywhere it appears.

Acceptance Criteria:

GIVEN - an Admin

WHEN - viewing a list of items that has paging

THEN - the list defaults to scrolling rather than paging.

S-92928 - Community - Performance Improvements to F_AuthenticateUser Database Function

We improved the performance of the F_AuthenticateUser Database function to optimize the login process for PBS Admin users. This enhancement ensures that logging into the Admin UI is faster, reducing wait times, and improving the overall user experience.

Example

As a...PBS Admin

I want...to be able to log into the Admin UI

So that...the login operation takes minimum time.

Acceptance Criteria:

GIVEN - the database definition for F_AuthenticateUser in the PBS database

WHEN - its definition is updated

THEN - login time is significantly reduced.

S-93588 - Community - Speedup of Far_117_23c1/c2

We have enhanced the runtime performance of the Far_117_23c1 and Far_117_23c2 rules by optimizing their implementation. Both of these rules rely on the underlying “SpecifiedTimeInMinutesHelper” rule, with the "UseFDP" option True. This rule examines time ranges by looking back from the end of each leg to check the amount of FDP within that range.

Previously, the Far_117_23c1 and Far_117_23c2 rules were taking about 56% of the runtime, as they used the end of every leg for the calculation. Now, these rules use only the end of the FDP END LEG (i.e. the last non-deadhead leg in the FDP). This enhancement significantly reduces not needed computations. Also, this enhancement results in up to a 73% speed increase for the affected rules, and an overall runtime improvement of up to 42% in some scenarios, such as the original QXE pilot run.

Note: This enhancement maintains identical rule outcomes, while simultaneously improving efficiency.

Acceptance Criteria:

GIVEN - a developer running a QXE pilot scenario similar to the original run in the ticket (ANC_CA_Final)
WHEN - completing the run before and after this code change
THEN - the run is faster post-change, and produces identical results.

GIVEN - a developer building the code with --rerun-tests (i.e. including rule unit tests)
WHEN - the rule unit tests are run (completed)
THEN - all rule unit tests, including those for Far_117_23c1 and Far_117_23c2, will pass—providing additional evidence that functionality remains not changed.

S-93752 - SCX - Pairings Tab - Not Filtering Redeyes/SOR/Charter

Pairings Properly

We enhanced the functionality of the Pairings tab by updating the filtering process to properly handle Redeye, SOR, and Charter pairings. Previously, these pairings were not being filtered correctly, however, with this update, users can now accurately filter and view Redeye, SOR, and Charter pairings as intended.

UAT - Redeyes

UAT – Charters

UAT – SOR

Acceptance Criteria:

GIVEN - a SCX Pilot Bidder

WHEN - using the Pairing Filter

THEN - the user sees the two new properties (SOR & TOA)

and

WHEN - entering an Award or Avoid Pairings Bid

THEN - I user sees the two new properties (SOR & TOA)

and

WHEN - using the Pairing Filter and enabling the SOR or TOA attribute

THEN - the system displays the appropriate trips that meet the criteria

and

WHEN - adding a bid preference (Award or Avoid bid)

THEN - the Bidder is able to include the SOR and/or TOA properties.

S-93373 - SCX - Rule Change - “IncludeLayoverDaysLocalTime” to be Changed to 0 (meaning False)

We improved the configuration of the “IncludeLayoverDaysLocalTime” setting by updating it to 0 (False). This enhancement involves modifying the baseline rule configuration XML file, updating the upgrade script, and editing the configuration spreadsheet to ensure consistency across all environments.

Acceptance Criteria:

GIVEN - a SCX Admin

WHEN - viewing the Rule Editor

THEN - the “IncludeLayoverDaysLocalTime” displays, changed from 1 to 0 within the Rule MinN.

S-94059 - SCX/COMMUNITY - Unable to Make Multi-Page PDF of Sorted Pairings

We improved the PDF export functionality for sorted pairings by updating the print service to correctly generate multi-page PDFs. This addresses an issue where only a single page was being saved regardless of the total number of pairings.

Note: The issue also occurs in other airlines.

Example

There are 220/1102 pairings that should be in the multi-page PDF

The root cause is the application of unsuitable CSS styles from css/app.css in the prints report page, which affected pagination. The enhancement involves modifying WebApp/js/services/printservice.js so that appropriate styles are applied, ensuring all pairings are included across multiple pages as expected.

Acceptance Criteria:

GIVEN - a Bidder

WHEN - attempting to filter and save a multi-page PDF of pairings

THEN - the Bidder receives a multi-page PDFdocument that includes all of my filtered pairings listed.

S-92666 - ACA - RGA Adding “Tagalog” Language

We enhanced the language support in PBS by adding “Tagalog” as an available language option, using “TA” as the designated 2-letter code. This update includes modifications to the upgrade script to ensure seamless integration of the new language across the system.

Acceptance Criteria:

GIVEN - an ACA & RGA ADMIN

WHEN - viewing the Languages Table

THEN - the new language “Tagalog” and language coded “TA” in the language qualifications display.

S-90410 - ASAP - (Configuration Only): Add Bid Property for Award Pairings, Time Off Before and After

For ASAP, we have improved the configuration of the Add Bid Property for Award Pairings, Time Off Before and After functionality. The enhancement involves adding the existing “Time Off Before and/or After” bid property to ASAP setup, making it available exclusively within the list of properties for an “Award Pairings” bid. This property allows Bidders to enter If Time Off Before and/or After, using either Days or Hours/Minutes.

Acceptance Criteria:

GIVEN - an ASAP Bidder

WHEN - adding a bid preference to the Award Pairing bid group

THEN - the new bid option “Time off before and time off after” available in hours and minutes, or as a number of days displays.

S-92687 - ASAP - Shadow Bidder Not Coming Up in I3

We enhanced the functionality of the Shadow Bidder feature by updating I3 to ensure that Shadow Bidders now properly display within the System.

Acceptance Criteria:

GIVEN - an ASA Planner

WHEN - exporting the I3 File

THEN - the Shadow Bidders display.

S-83552 - ASAP - (Config Only): Add Set Condition “Consecutive Days Off in a Row” to Reserve Bid Group

We enhanced the configuration for ASAP by adding the existing bid option “Set Condition Consecutive Days Off In a Row” to their Reserve Bid Groups.

Acceptance Criteria:

GIVEN - as a Bidder

WHEN - a Reserve Bid Group is created

THEN - the Set Condition “Consecutive Days Off in a Row,” in both the Default and Current tab can be added and submitted.

S-91756 - ASAP- Reserve-TotalDaysOnUsingCreditProration Rule Change - Part 1: Configuration Only

We have enhanced the configuration of the Reserve-TotalDaysOnUsingCreditProration rule by introducing a new parameter, IncludeVirtualCredit. This parameter is now read into the rule and stored as a member of the class: ReserveTotalDaysOnUsingCreditProrationRule.

Note: For Part 1 (Configuration Only), the parameter is set to True for ASAP, and False for other customers. Although the parameter is now part of the configuration, it does not affect the rule’s functionality until it is implemented on a future update (Part 3).

An upgrade script is required, and the configuration spreadsheet has been updated to reflect this enhancement. These updates lay the groundwork for future functionality that will allow the rule to take “Virtual Credit” into account when calculating Reserve Total Days On using credit proration.

Acceptance Criteria:

GIVEN - an Admin for a customer with this rule and the new parameter set to True (ASAP)
WHEN - viewing the Rule Editor
THEN - the new parameter displays with the correct value (1/True).

GIVEN - an Admin for a customer with this rule and the new parameter set to False (e.g. NKS)
WHEN - viewing the Rule Editor
THEN - the new parameter displays with the correct value (0/False).

S-83254 - DAL - Export PVPP code (preceding code before Vacation)

We implemented new functionality to enable the export of PVPP codes in the Absence Export file (Delta (O03) Export) for a valid, completed run.

Typically, the PVPP codes are imported to the N-PBS system via the “Delta Employee, Absences & History” file, and not included in the Delta (O03) Export. PVPP codes are always two days prior to the Vacation block (PVAC).

With this enhancement, when a crewmember bids for a Slide Vacation (Set Condition→Slide Vacation) in the WebApp, the associated PVPP days are now correctly slid and included in the export. In the exported file, PVPP days are now placed before the PVAC absences.

Acceptance Criteria:

GIVEN - an DAL Admin

WHEN - exporting the Awards

THEN - the PVPP code exported along with the PVAC code is displayed.

S-90042 - DAL - Short Call - *New* Absence Code Flag

We have enhanced the Absence Code configuration interface by adding a new sub-item, Max Short Call, on the same line as Prorated Days Off, next to Reserve and Pairings. Also, the parameter Prorated Days Off is renamed to Prorates, and related parameters names are updated accordingly. These enhancements are only visible for customers with Daily Short Call (e.g., DAL) (New setting in user type options).

The Max Short Call checkbox is functionally related to the Prorates checkbox, similar to the relationship between Reserve and Pairings. The value is saved to the database in the same manner as other Absence Code flags.

To accommodate the new sub-item and updated naming, column widths are adjusted. Also, an upgrade script is required to add the new flag, which is set to False for all existing Absences.

Note: DAL and other customers can update the flag, as desired.

Note: The renaming of proration options and the addition of the Max Short Call flag are documented in the change log.

Acceptance Criteria:

GIVEN - a DAL Admin

WHEN - adding/editing Absence Codes

THEN - the checkbox for Short Call appears next to Reserve and Pairings, on the same line as Prorated Days Off

and

THEN - the checkbox is related to the Prorated Days Off checkbox, similar to Reserve and Pairings

and

THEN - this checkbox is not checked initially for all Absence Codes

and

WHEN - saving the Absence Code, then logging out and back in

and

THEN - the option displays in the Absence Code view table

and

THEN - the Absence Code is retained.

GIVEN - a Non-DAL Admin

WHEN - adding/editing Absence Codes

THEN - the checkbox for Short Call does not appear next to Reserve and Pairings, on the same line as Prorated Days Off

and

THEN - the existing functionality for the other checkboxes (Reserve and Pairings) continues to work.

S-90044 - DAL - Short Call - *New* Category “Max TDA Item”

We have enhanced the user interface for DAL by adding a new “Max TDA” tab next to the existing ALVs tab. This new tab functions in the same way as the ALVs tab.

To support this enhancement, we have implemented database storage for Max TDA values, following a structure similar to ALVs. Through an upgrade script, the initial value 5 for every category is implemented. Users can edit this value, with a maximum value of 99 allowed.

Also, visible only for DAL users, we have added a “MAX TDA” field (allowing values up to 99) to the add/edit category screen, located below the ALV field.

S-90045 - DAL - Short Call - *New* Rule “Max SC Per Person” including Proration Table - Part 1 Rule Configuration

We have enhanced the Reserve rules configuration by introducing a new rule, Reserve-MaximumShortCallPerPerson, which allows more precise control over the maximum number of Short Call assignments per individual, based on proration.

This enhancement improves on the previous configuration by aligning the Maximum Short Call Per Person rule with Delta’s requirements and providing clearer, table-based proration logic.

This enhancement is Part 1 of the project and focuses on the Rule Configuration only.

Delta has provided the following:

Currently, for the Reserve Total Days Off rule, Delta selects from a dropdown menu of eight proration table options for each run.

Also, there is a flag that indicates which absences are required to prorate the Max (Maximum) Short Call per person.

Functionality:

There are eight proration tables configured for the Reserve-MaximumShortCallPerPerson rule. These tables correspond directly to the eight possible selections Delta makes from the Reserve Total Days Off dropdown list.
There is not a separate dropdown to select the proration table for MaximumShortCallPerPerson. Instead, PBS automatically determines which proration table to use for MaximumShortCallPerPerson based on the selection made from the existing Reserve Total Days Off dropdown.
These eight tables contain the values provided by Delta (from the two tables imaged above). However, having eight separate tables makes it clear exactly how the system chooses which table to use for each run.

How the Tables Work:

The numbers in these tables map the “Number of Prorating Days” to the “Max Short Call Items.”
- For this rule, “Number of Prorating days” refers to the number of in-period days that contain an absence flagged as “Prorates Max Short Call.”

Example

When the tables provided by Delta refer to “29-31 reserve days,” this actually means “29-31 days which are not prorating days.” In a 31-day period, this equates to “0-2 prorating days,” or “0-1 prorating days” in a 30-day period.

A table with numbers and a number of days

AI-generated content may be incorrect.

Table Format:

The configuration parameters (in our configuration and available in the Rule Editor) use the same format as the Reserve-TotalDaysOff rule: pairs of numbers.

Example table for a 30-day period:

etc. (7 other tables).

If a person has 12 prorating days (i.e., days with absences flagged as “Prorates Max Short Call”), the table maps them to a maximum of 3 Short Call items.
This format is repeated for all eight proration tables, each corresponding to a selection in the Reserve Total Days Off drop-down.

Implementation: An update script is required to add this rule and update the configuration spreadsheet.

Note: For this Part 1 release, Scheduler does not implement the rule logic. However, a few lines of code are added to ReserveAllocator::PopulateRules to ensure this rule is skipped during the main run, allowing the process to complete successfully.

Acceptance Criteria:

GIVEN - a DAL Admin

WHEN - viewing the Rules Editor

THEN - the new rule displays along with its parameters, as described.

S-93647 - DAL - Short Call - *New* Rule “Max SC Per Person” including Proration Table - Part 2 Rule Implementation

We have enhanced the scheduling functionality by implementing the new Reserve-MaximumShortCallPerPerson rule. This update is Part 2 of the project, focusing on the Scheduler’s enforcement of the rule (with Part 1 (S-90045) introducing the rule configuration).

Note: As of February 24, 2025, PBS uses eight proration tables for this rule. This corresponds to the eight proration tables names available in the “Reserve Total Days Off” dropdown menu. For each run, Delta selects one table name, which determines both the proration table used for “Reserve Total Days Off”, and for the Reserve-MaximumShortCallPerPerson rule.

For each period length (30 or 31 days), the selected proration table maps the “Number of prorating days”—defined as the number of in-period days containing absences flagged as "Prorates Max Short Call"—to the “Max Short Call Items”.

Example

In a 30-day period, the table might include pairs such as:

0,6
1,6
2,5
3,5
and so on, up to 30,0.

If a person has two prorating days (i.e. Days which contain absences that are Prorate Short Call flag), the table maps them to have a maximum of five “Short Call Items”.

The Scheduler now actively enforces this rule during Short Call Awards.

Note: Currently, this rule is detailed in the “crwTN - PBS Rules For Reserve Lines - Excluding FARs And CARs” document. If a comprehensive Daily Short Call Living document is created in the future, documentation for this rule will be migrated there.

Acceptance Criteria:

GIVEN - a Scheduler run for DAL

WHEN - completing the Short Call allocation

THEN - the Scheduler enforces the “Maximum Short Call Per Person”, applying the appropriate Short Call Proration Table. Note: This depends on which table the Administrator selects for the run.

S-90038 - DAL - Short Call - Admin UI Report

We implemented a new sub-tab within the Reports tab, called “Daily Short Call Report,” to enhance reporting functionality for Short Call data. This new sub-tab allows users to generate detailed reports using Short Call data, for all categories collectively or for each category separately.

A User Interface (UI) similar to the Pairing Report has been adopted for consistency and ease of use (see Screen 1 and Screen 2 below). The interface includes:

Dropdown menu: Allows selection of “All” or individual categories.
Generate Report button: Initiates the report generation process.

Screen 1

Screen 2

Note: The Admin UI report is similar to the table below, however there is a separate table for each category.

In addition, all tables are sorted by Start date and time, with the same report options as the Pairing Report.

Basic Case

Precondition: The Admin has imported a Short Call file for a period.

Steps:

Log in to the Admin UI.
Navigate to the Reports tab.
Select the Daily Short Call Report sub-tab.
Use the dropdown to select “All” or a specific category.
Click the “Generate Report” button to display the data.

Note: Reports are generated in HTML format.

Acceptance Criteria:

GIVEN - an Admin and/or Scheduler

WHEN - accessing the “Reports” tab

THEN - the “Daily Short Call Report” sub-tab displays.

GIVEN - an Admin and/or Scheduler

WHEN - accessing the “Daily Short Call Report” sub-tab

THEN - a report for all or a selected category can be generated.

GIVEN - an Admin and/or Scheduler

WHEN - clicking the “Generate Report” button

THEN - the report is generated in the HTML format.

S-90036 - DAL - Short Call - Database table

We enhanced the database for Short Call management by introducing a new table, Daily Short Call Item, designed to efficiently store and organize Daily Short Call data. The table structure is as follows:

RecId (Primary Key): Unique identifier for each record
FalconCategory_RecId: Linked to the FalconCategory
StartDateTime (UTC)
EndDateTime (UTC)
Length: Number of days for the Short Call.
IsFRMS (Boolean)
Identifier (String)
CountShortCall: Number of available positions.

Note: A Unique Index, DailyShortCallItem_CategoryIdentifier (Category, Identifier)has also been added.

In addition, to support streamlined operations and data consistency, we enhanced the following stored procedures:

SP_AddDailyShortCallItem
SP_ImportClearPeriodDailyShortCallItems.

Additionally, we added PeriodData.pl to handle Daily Short Call Items with Period Copy testing, and added a data access layer code.

Note: An upgrade script has also been added.

Acceptance Criteria:

GIVEN - a Developer

WHEN - reviewing the PBS database SCHEMA

THEN - the DailyShortCallItem Table and its associated stored procedures, as described, are displayed.

GIVEN - a Developer

WHEN - testing the stored procedure SP_adddailyshortcallitem manually in the database

and

WHEN - testing the stored procedure SP_import_clear_period_dailyshortcallitems manually in the database

THEN - it successfully works.

GIVEN - a Developer

WHEN - upgrading a database

THEN - the new table and new stored procedures display.

S-90052 - DAL - Short Call - Export O03 Format

We enhanced the Short Call export functionality by updating PBS to include Short Call Period awards in the O03 export format, alongside other award information.

A new record type (Type 3) is now introduced to support this enhancement. The following data fields are now exported:

Record Type
Employee Number
Shadow Bidder
Base-Equip-Seat
Reserve Indicator: S
SC Start Date
SC Start Time
SC End Date
SC End Time
TDA
FRMS Indicator (blank if not)
Short Call Period Name

*SC= Short Call

For example, in the export file:

Record Types 1 and 2 represent existing formats.
Record Type 3 is the new format for Short Call Period awards.

Example Export:

0,01JAN25,30JAN25

1,016301200,,ATL-765-A,S,11JAN25XX,12JAN25XX,13JAN25XX,18JAN25XX,19JAN25XX,20JAN25XX,21JAN25XX,27JAN25XX,28JAN25XX,29JAN25XX,30JAN25XX,

2,016301200,,ATL-765-A,S,01JAN2504JAN25PVAC,

3,016301200,,ATL-765-A,S,11JAN25,1108,11JAN25,1708,5,F,SC088,21JAN25,1108,21JAN25,1708,4,F,SC131,

1,038812300,,ATL-765-A,S,01JAN25XX,02JAN25XX,03JAN25XX,04JAN25XX,05JAN25XX,06JAN25XX,07JAN25XX,08JAN25XX,09JN25XX,26JAN25XX,

2,038812300,,ATL-765-A,S,19JAN2525JAN25FVAC,

3,038812300,,ATL-765-A,S,04JAN25,0700,04JAN25,1300,3,,SC023,19JAN25,0700,19JAN25,1300,3,F,SC108,

Note: In the above example, Record Types 1 and 2 are existing Record Types.

Acceptance Criteria:

GIVEN - a DAL O03 export for a concurrent run

WHEN - a crewmember has one or more Daily Short Call Item awarded

THEN - Record Type 3 appears for them in the export file, following the specified format, with one line potentially containing multiple Short Call awards.

S-90037 - DAL - Short Call – Import

For DAL, we have enhanced the import configuration by introducing a new import file type and import group type to support the Daily Short Call process. This new import type follows the same configuration used for other import file types and group types.

Note: An upgrade script is provided to add these new types to the system.

Example Import File:

0,01NOV24,30NOV24

1,ATL,73N,A,11NOV24,1000,11NOV24,1600,2,,SC001,1,

1,ATL,73N,B,11NOV24,1000,11NOV24,1600,2,,SC002,1,

1,DTW,320,A,12NOV24,1600,12NOV24,2200,2,,SC001,1,

1,LAX,7ER,A,13NOV24,1700,13NOV24,2300,2,,SC001,1,

1,ATL,350,A,14NOV24,2140,15NOV24,0340,5,F,SC003,1,

1,ATL,350,B,14NOV24,2140,15NOV24,0340,5,F,SC004,1

1,ATL,350,B,15NOV24,2140,16NOV24,0340,5,F,SC005,2,

1,LAX,7ER,B,16NOV24,0400,16NOV24,1000,2,,SC002,1,

1,LAX,7ER,A,17NOV24,0400,17NOV24,1000,2,,SC003,1,

1,LAX,7ER,B,18NOV24,0400,18NOV24,1000,2,,SC004,1,

1,LAX,7ER,A,19NOV24,0400,19NOV24,1000,2,,SC005,1,

1,LAX,7ER,B,20NOV24,0400,20NOV24,1000,2,,SC006,1,

1,LAX,7ER,A,21NOV24,0400,21NOV24,1000,2,,SC007,1,

1,LAX,7ER,B,22NOV24,0400,22NOV24,1000,2,,SC008,1,

1,DTW,350,A,23NOV24,0400,23NOV24,1000,4,F,SC002,2,

Description of fields for Record Type 0

Record Type (0=header 1=SC Item)
Period Start date
Period End date

Description of fields for Record Type 1

Record Type (0=header 1=SC Item)
Base: three-letter base identifier
Equipment: three-character equipment identifier
Position: either “A” or “B”
Start date: DDMMMYY (only during the period - otherwise error) (local time)
Start time: HHMM (local time)
End date: DDMMMYY (only during the period - otherwise error) (local time)
End time: formatted as HHMM (local time)
TDA value: numeric value between 1 and 18
FRMS indicator: “F” to indicate the SC period is an FRMS SC period or blank
Identifier (string is provided) - Max 18
Count: how many positions are available.

Main tasks:

Create a new UI entry for the Daily Short Call file - Daily Short Call.
Create a new column “Daily Short Call” in the Pairing Data Status section. The import results display in green, e.g., DSC/225 where DSC means Daily Short Call, and 225 is the number of imported records.
This enables import processing on the backend, and allows storing of the imported data in the database.

Basic Business Scenario:

Log in as an Admin to the Admin UI.
Access the Periods tab.
Select a period.
Import a Daily Short Call.

Validation Rules Enforced

For Record Type 0:

The start and end dates must exactly match the start and end date of the period.

For Record Type 1:

Either the end date equals the start date and end time, or the end time is after the start time, OR the end date is the day after the start date and end time, where the end time is less than or equal to the start time.
- i.e. Either end date=start date and end time > start time OR end date=start date + 1 day and end time < or = start time.
The TDA value must not exceed the category’s maximum TDA (defined in DAL Short Call category “Max TDA Item”).
Identifier length must not exceed 18 characters.
Identifiers must be unique within a category (duplicates cause an error).
Start date/time must fall within the period.
Each line must have 13 fields, separated by 12 commas, with the last field blank.
All fields except the FRMS indicator and last field must be filled in and correctly formatted (date, time, number).
Identifiers must contain only letters and numbers. Note: Lowercase letters are converted to uppercase letters.

Acceptance Criteria:

GIVEN - a Scheduler and/or Admin

WHEN - importing a Daily Short Call file

THEN - a new entry on the dropdown list called Daily Short Call appears

and

THEN - a new column showing Daily Short Call Items EG: DCS/225 displays.

GIVEN - a Scheduler and/or Admin

WHEN - importing a Daily Short Call file

THEN - the import is successful and the import results display in the column Daily Short Call (DCS/225).

GIVEN - a Scheduler and/or Admin

WHEN - importing a Daily Short Call file with data that is not correct

THEN - the import fails and an import error message is displayed, indicating the specific line with the error and describing the error type (as per description).

S-90559 - DAL - Short Call - Roster Report

We enhanced the Roster Report functionality for Daily Short Call (DSC) Item. It now displays the full character of the identifier and the actual start and end times.

Acceptance Criteria:

GIVEN - a DAL Admin

WHEN - viewing the Roster Report

THEN - the DSC item with the full character of the identifier and the actual start and end times displays.

S-90047 - DAL - Short Call - Rules for “Time Off Before SC” - Part 1

Rule Configuration

We enhanced the configuration for Short Call and added a new rule: Reserve-RestBeforeShortCall. This rule introduces two parameters: minutes before non-FRMS (660 minutes, or 11 hours DAL), and minutes before FRMS (1500 minutes, or 25 hours DAL). This is Part 1, and introduces the rule configuration only. For Part 1, the Scheduler does not enforce the rule, however, a code is added to ReserveAllocator::PopulateRules. This ensures that the rule is skipped during the main run, thus allowing the process to complete successfully.

Note: This enhancement includes both an upgrade script and updates to the configuration spreadsheet.

Acceptance Criteria:

GIVEN - a DAL Admin

WHEN - viewing the Rules Editor

THEN - the new rule with its parameters, as per the description, displays.

S-93646 - DAL - Short Call - Rules for “Time Off Before SC” - Part 2

Rule Configuration

We have enhanced the configuration of the Short Call by adding a new rule: Reserve-RestBeforeShortCall. This is Part 2, which covers the Scheduler implementation of the rule and builds on the configuration established in Part 1. This rule has two parameters: minutes before non FRMS, 660 (11 hours DAL), and minutes before FRMS, 1500 (25 hours DAL).

The rule mandates that there must be no pre-awarded pairing, or absence with the work-for-duty flag, or other Short Call Item within the required time before the Short Call Item. The rule uses the exact start time of the individual Short Call Item and the FRMS flag to determine which value to enforce.

Note: Regular Reserve Items (RES) are exempt and do not violate the rest requirement.

Also, the Scheduler now applies and enforces this rule during Short Call awards

Note: Currently, this rule is documented in the “crwTN - PBS Rules For Reserve Lines - Excluding FARs And CARs” document. If a comprehensive Daily Short Call living document is created in the future, the documentation will likely be moved there.

Acceptance Criteria:

GIVEN - a Scheduler run for DAL

WHEN - completing the Short Call allocation

THEN - the Scheduler enforces the required rest before Short Call, including cases FRMS/non-FRMS, and with pairings before, absences before, and other SC before.

S-90049 - DAL - Short Call - Schedule Report

We implemented new functionality for the Short Call - Schedule Report to enhance clarity and usability. The report now displays the first four characters of the identifier, along with the actual start and end times for each item.

Example

If an item crosses midnight and there is another item on the same day, the report now displays a second row for the additional item.

Acceptance Criteria:

GIVEN - a DAL Admin

WHEN - viewing the Schedule Report

THEN - the DSC item with the first four characters of the identifier with the actual start and end times displays.

S-90048 - DAL - Short Call - Scheduler Algorithm Basic Part 1

We implemented new functionality for processing Short Call bids, using hard-coded bids temporarily added within the method CoreHlbManager::CreateOriginalBidGroups. This approach in the future replaces enhancement S-93545 to integrate actual Bid UI bids.

This enhancement allows the Scheduler to load Short Call Items and the maximum TDA for each category when loading run data, with both actions logged in the schedule log file. During post-processing, Reserve Lines are handled in seniority order.

For each Short Call identifier bid in the final used bid group, if a matching Short Call Item is available (i.e., not all counts have been filled by Seniors) and the individual has a Reserve Day awarded on the corresponding date (the start date of the Short Call item), the Scheduler awards the item.

When a user is awarded a Short Call Item, they keep the Same Day Reserve Award; however, the Scheduler updates the award’s alias and adjusts the start and end times accordingly. Note: This process is consistent with the existing post-process Call Type coloring functionality.

Acceptance Criteria:

GIVEN - a Scheduler run that includes Reserves with Daily short call (DAL)

WHEN - completing the run

THEN - the Scheduler does a post process allocation of Short Call Items

and

WHEN - processing an individual user that got a Reserve Line

THEN - all Short Call bids in the final Reserve bid group are processed (using the currently hard-coded bids)

and

WHEN - processing an individual users’ Daily Short Call bid for one identifier

THEN - the Scheduler awards the Short Call Item if a matching item is available (i.e., not all of the count is filled by more senior users) and the user has a Reserve Day awarded on the corresponding date (the start date of the Short Call Item)

and

WHEN - an individual user is awarded a Short Call Item

THEN - the user keeps the Same Day Reserve Award, however, the Scheduler changes the alias on the award, and the start/end time.

S-93544 - DAL - Short Call - Scheduler Algorithm Basic Part 2

We have enhanced the Short Call awarding process by introducing three additional validation checks on top of the existing Scheduler Algorithm Basic Part 1. These new checks ensure more accurate and compliant assignment of Short Call items:

Item #1 (ULC Line Restriction):
If an individual is assigned a ULC (Ultra Long Call) line, they are not eligible to receive any Short Call items.
Note: This scenario should be prevented by bidding restrictions, however the check is enforced as an added safeguard.
Item #2 (Shadow Period Restriction):
A Short Call item may not be awarded for any individual in a shadow period.
Item #3 (Reserve Day Validation):
The assignment of Short Call items is now subject to stricter Reserve Day requirements. If the person does not have the appropriate Reserve Days, after the Current Reserve Day, they should not be awarded the item:

If the Short Call item’s TDA equals the maximum for the category:
The person must have at least that many Consecutive Reserve Days, starting from the start date of the Short Call item.

Example: For a Short Call item with TDA 5 starting on the 10th, the person must have reserve on the 10th, 11th, 12th, 13th, and 14th.

May or may not have Reserve on the 15th, 16th ECT
May or may not have Reserve on the 8th, 9th ECT

If the Short Call item’s TDA is less than the maximum for the category:
The person must have exactly that many Consecutive Reserve Days, starting from the start date of the Short Call Item.

Example: For a Short Call item with TDA 4 starting on the 10th, the person must have Reserve on the 10th, 11th, 12th, and 13th, and must not have reserve on the 14th.

They must NOT have Reserve on the 14th
May or may not have reserve on the 8th, 9th ECT

Acceptance Criteria:

GIVEN - a Scheduler run that includes Reserves for a customer with Daily Short Call (i.e. a DAL Concurrent run)

WHEN - processing Daily Short Call bids for a user who got a ULC line (i.e., their Reserve Line is awarded from a Reduced Reserve Line bid group, referred to as “ULC” by Delta)

THEN - this user is not awarded any Daily Short Call Items

and

WHEN - processing a Daily Short Call bid for an individual, if the Short Call Item starts on a date that falls within a shadow period

THEN - the individual is not awarded that particular Daily Short Call Item

and

WHEN - processing a Daily Short Call bid for an individual, if they do not have the appropriate Reserve days following the item (as per description)

THEN - the person is not awarded that particular Daily Short Call Item.

S-93545 - DAL - Short Call - Scheduler Algorithm Basic Part 3 (Integrating with Bid UI bids)

We enhanced the Daily Short Call bidding process by integrating actual bids from the Bid UI, building on the foundational work completed in S-90048 (Scheduler Algorithm Basic Part 1), which previously used temporary hard-coded bids. The system now uses the BidVisitor to convert submitted bids into Scheduler-Internal bids (AwardDailyShortCallCoreHlb items):

If a single bid is marked as “Ordered”: Multiple scheduler-internal bids are created (one for each item) to reflect the order.
If a single bid is not marked as “Ordered”: Only one scheduler-internal bid is created, as all identifiers are treated with equal preference.

Processing of these bids continues as before, with items awarded only if the identifiers match and it is legal for the individual to be awarded the item.

Acceptance Criteria:

GIVEN - a Scheduler run completing post-process Daily Short Call allocation (i.e. a DAL Concurrent run)

WHEN - processing Award Short Call If Identifier bids that are entered using the Bid UI

THEN - the Scheduler processes those bids in preference order, considering each Daily Short Call Item that matches each bid, and awarding it if it is available and legal to award to the individual.

and

WHEN - an individual submits an Award Short Call If Identifier bid with multiple items and selects the “Ordered” option

THEN - the Scheduler processes this internally as a series of separate, preference-ordered bids—one for each item—to reflect the preference order of the bid.

S-93724 - DAL SC - WebApp Bid by Identifier Bid Visitor

We enhanced the bidding functionality by implementing the bid visitor for the new bid type, “Award Daily Short Call If Identifier XXXXX.” This allows the bid to be submitted and displayed on the Admin UI Bid Manager’s Bids tab.

Note: The Scheduler visitor BaseCoreHlbVisitor is left blank.

Acceptance Criteria:

GIVEN - a DAL bidder

WHEN - submitting a bid that includes an Award Daily Short Call If Identifier bid

THEN - the bid submits successfully.

GIVEN - a DAL Admin

WHEN - viewing the Bid Manager for a crewmember who has submitted an Award Daily Short Call If Identifier bid

THEN - the bid with the correct syntax displays.

S-91562 - DAL SC - WebApp Bid by Identifier Phase One

We introduced new functionality for Short Call bidding, including C++ file generation, a new bid option with a drop-down list of identifiers, bid configuration, and enforced placement below other bids. Mutual exclusivity between ULC (Reduced Reserve Line) and Short Call is now configurable, ensuring that a Bidder can select either ULC or Short Call within a bid group, but not both.

When a crew member bids for a Reserve Bid group with preferences and then Short Call with preferences, Short Call always appears at the bottom of the Reserve Bid group. If no preferences are specified within the Reserve Bid group, Short Call displays directly below:

A close up of text

AI-generated content may be incorrect.

Mutually Exclusive = A Bidder can either bid for ULC or SC in a Bid Group– not both.

If a crew member attempts to bid for both, the system displays a clear conflict message in red (shown below), similar to those for minimum credit window and RCL conflicts:

Add Bid Group BidLine of type (Ultra Long Call) conflicts with existing bid line OR
Add Bid Group BidLine of type (Short Call) conflicts with existing bid line.

New bid group within an applied Reserve Bid Group

The options in the Short Call bid group are limited to “Award Only,” and Short Call should be bid based on identifier numbers in the “Award" section”, following the established format:

Note: For Phase One, the Scheduler does not implement “If/If Not”, however, this can be implemented if needed, and NAVBLUE can deconfigure it.

The enhancement also supports a list of identifiers for Short Call bidding, with the option to select “Ordered: YES or NO,” similar to the “Pairing Departing On” functionality.

Acceptance Criteria:

GIVEN - a DAL Bidder

WHEN - adding a Reserve Bid Group

THEN - the new bid option within the Reserve Bid group called “Award Short Call” shows

and

WHEN - the "By Identifier" Option is selected

THEN - a dropdown of all of the Identifiers available for the category appears.

GIVEN - a DAL Bidder

WHEN - a Reserve ULC bid group to my bid is added

THEN - SC can not be added to that same Bid Group, and that Bid Group can not be added to SC

and

WHEN - a crewmember attempts to add ULC and Short Call

THEN - the message Add Bid Group BidLine of type (Ultra Long Call) conflicts with existing bid line

OR Add Bid Group BidLine of type (Short Call) conflicts with existing bid line appears.

S-90432 - DAL - DSC - DSC Run Report

We have introduced a new feature that allows customers to generate reports related to Short Calls, directly after a run is completed.

Note: The report can be generated regardless of whether the run is valid. This enhancement streamlines the reporting process for Short Calls, making it easier to access and review relevant data following each run.

Note: The infrastructure where the Scheduler outputs the relevant information into PbsResults is already written.

This report includes the following information:

results of the run
who was awarded DSC (employee number and name)
the remaining DSC patterns.

Example business scenario

Preconditions: All required files, including Daily Short Calls, are imported and Bidders have submitted their preferences. As well, at least one run is completed.

1. Log in to the Admin UI.

2. Navigate to the Run Manager tab and select the “Completed” sub-tab.

3. Select a run from the list.

4. Click the “...” button to generate the report.

Example

Daily Short Call Report

Period: SEP 2024

Category: ATL-765-A

Run: doug_2

Awards:

Employee First Name Last Name IDENTIFIER START END TDA FRMS

------------------------------------------------------------------------------------------------------------------------

12345 John Doe IDENTIFIER1 02JUL24,1600 02JUL24, 2359 4 F

IDENTIFIER2 016JUL24,0900 16JUL24,2200 4

ECT

Summary

START IDENTIFIER END TDA FRMS COUNT AWARDED REMAINING

------------------------------------------------------------------------------------------------------------------------

20240901/1245 ABCDE 20240901/2245 4 10 6 4

20240901/1445 FGH 20240901/2345 5 F 15 9 6

ECT

TOTAL 256 150 106

Note: This information appears in the Combined Reports section of a completed run

(see highlighted area below in green):

There are no additional options for generating the report, and Employees are listed by seniority, with the most senior at the top and the most junior at the bottom.

Note: Based on the above image design, the below image is produced:

Acceptance Criteria:

GIVEN - a DAL Admin

WHEN - viewing the Reports page for a completed run

THEN - the new DSC Run Report, within the Combined Report displays

and

THEN - it displays the details listed above, including the run results, employee number, employee name, and the remaining DSC patterns in the reports section.

S-87929 - FFT - “Eligible for Training” Import Feature

We have added the ability to enable or disable the “Eligible for Training” option through the Crew Eligibility import file, in the same way as other crew member attributes.

Acceptance Criteria:

GIVEN - a FFT Admin

WHEN - importing files

THEN - it is possible to import an “Eligible for Training” file.

S-88226 - FFT - Waive Bid Option - Remove “No Same Day Pairings/Trips” and Replace it with “No Same Day Duties Start”.

We improved the scheduling system by removing the “No Same Day Pairings/Trips” rule and its associated Waive bid, and replaced it with the new “No Same Day Duties Start” rule and corresponding Waive bid.

In addition, the configuration spreadsheet is updated to reflect this change.

Note: An upgrade script is also added to ensure that any existing instances of the waived “No Same Day Pairings” rule in users' most recent bids are removed, thus using the standard bid upgrade script.

Acceptance Criteria:

GIVEN - a Bidder

WHEN - viewing Waive Bid options in a Pairing Bid Group

THEN - “No Same Day Pairings/Trips” does not display

and

THEN - “Waive No Same Day Duties Start” displays.

GIVEN - an FFT Admin

WHEN - viewing the Rule Editor

THEN - the old rule, “No Same Day Pairings/Trips” does not display

and

THEN - the new rule, “No Same Day Duties Start” displays.

GIVEN - an FFT Bidder who has included the “Waive No Same Day Pairings” bid in their most recent Current or Default bid prior to the upgrade

WHEN - the upgrade is complete

THEN - that bid is removed

and

THEN - other bids are renumbered as appropriate.

GIVEN - an FFT Admin performing a run in a category where a Bidder has used the “Waive No Same Day Duties Start” bid and bid for a combination of trips that can only be honored if the Waive bid is correctly processed

WHEN - the run is complete

THEN - the combination of trips is honored, confirming the Waive bid worked.

S-87089 - FLE - Bid Option - RedEye (Pilots and Fight Attendants)

We added RedEye functionality to the FLE Bid configuration for Award, Avoid, and Filter options for both Pilots and Flight Attendants (FAs).

The RedEye definition for FLE is: any leg with a local time departure between 03:30 and 04:59 (inclusive), or arrival at exactly 03:30. Specifically:

A leg departing exactly at 04:59 is considered RedEye.
A leg arriving exactly at 03:30 is considered RedEye.

Note: This definition is also added to the FLE Crew Plan Converter, using the existing FleCrewPlanConverter file created under S-87526.

Note: An update Configuration spreadsheet is required.

Acceptance Criteria:

GIVEN - a FLE Bidder

WHEN - bidding

THEN - the option to Award/Avoid/Filter RedEyes displays.

GIVEN - a FLE Admin

WHEN - N-OC pairing import

THEN - the correct pairing is flagged as RedEye and can be verified using the Bid UI pairing search.

GIVEN - a FLE Admin

WHEN - completing a CrewPlan pairing import

THEN - the correct pairing is flagged as RedEye and can be verified using the Bid UI pairing search.

S-93727 - FLE - Handle 3 - Character Crew Classification for CrewPlan Imports

We have enhanced the CrewPlan pairing parser to support FLE’s non-standard crew classification format in the “Pairing Master Record” (Record Type 1). Currently, CrewPlan has eight “Positions” at positions 114–145, each consisting of two characters for crew classification followed by two digits for crew count (e.g., CA01 for one CA). However, FLE requires support for three-character crew classifications, such as IFD1FA03 (representing 1 IFD and 3 FA). This enhancement accommodates FLE’s request, as the parser now recognizes both three character classifications followed by a single digit, and two character classifications followed by two digits. For example, one of their positions string from their import files:

IFD1FA03 represents 1 IFD and 3 FA.

Note: This is not a fixed format, it is either three characters followed by one digit, or two characters followed by two digits, which complicates processing of the file. Due to the flexible format, there is potential for ambiguity if a crew classification includes digits and characters (e.g., FA1), as FA11 could mean either 1 FA1 or 11 FA. While this scenario is not likely, it is now possible.

Acceptance Criteria:

GIVEN - a non-standard FLE Crew Plan file

WHEN - importing that file

THEN - the import is successful.

S-87526 - FLE - Import for S3RUS - Pairings→(CrewPlan)

We implemented new functionality to support the import of FLE Crew Plan files in PBS, alongside the existing import formats. This enhancement introduces a new import format to the PBS Settings .xml for FLE FleCrewPlan, including both the import file type and import group type.

To enable this functionality, the Database Schema has been enhanced to add the new import type, which requires an upgrade script. The import code has also been updated to recognize and process the new import type, and a dedicated FLE Crew Plan Converter has been introduced to handle the file conversion.

Note: The Configuration spreadsheet is updated to reflect these changes.

Acceptance Criteria:

GIVEN - a FLE Admin

WHEN - viewing the Import screen

THEN - the CrewPlan Pairing import option displays

and

THEN - it is possible to complete a CrewPlan pairing import.

S-90760 - FLE Pilots - Consecutive WOCL Duties Car_700_51

We have enhanced the WOCL (Window of Circadian Low) duty Car_700_51 limitation in PBS by introducing a new configuration parameter, Max2ConsecutiveWOCLsinsteadof3. This parameter is configured to ‘True’ for FLE and ‘False’ for all other ALCs. When this parameter is set to ‘True,’ the maximum number of consecutive WOCL duties is limited to two instead of the previous maximum limit of three. This update applies specifically to FLE, while all other ALCs will retain the existing limit.

Also, the extended maximum of five consecutive WOCL duties has not changed, and all other details of this rule remain the same as before.

Note: An update to the Configuration spreadsheet and Rules Reference Manual is required. An upgrade script is also required to implement this enhancement.

Acceptance Criteria

GIVEN - a FLE Admin

WHEN - viewing the Rule Editor

THEN - the new parameter with the value (1) displays.

GIVEN - a non-FLE Admin

WHEN - viewing the Rule Editor

THEN - the new parameter with the value (0) displays.

GIVEN - a build being done with unit tests

WHEN - running the CAR_700_51 unit test

THEN - this includes testing the new parameter: Max2ConsecutiveWOCLsinsteadof3 (automated test ONLY).

S-90833 - JBU - Add New Languages to the Database

For Jetblue, we have enhanced the system database by adding support for multiple new languages. This update requires an upgrade script to seamlessly add the new languages, ensuring broader accessibility and improved user experience.

The newly added languages and their corresponding codes are listed below:

Arabic- AR
Cantonese- CA
Chinese- CH
Creole- CR
Croatian- CT
Czech- CZ
Danish- DM
Dutch- DU
Flemish- FL
German- GE
Greek- GR
Hebrew- HE
Hindi- HI
Italian- IT
Japanese- JA
Korean- KO
Mandarin- MA
Norwegian- NO
Polish- PO
Portuguese- PR
Punjabi- PU
Romanian- RO
Russian- RU
Swedish- SW
Taiwanese- TA
Thai- TH
Turkish- TU
Ukrainian- UK

Acceptance Criteria:

GIVEN - a JBU Admin

WHEN - viewing the Languages Table

THEN - the new languages and language codes in the language qualifications displays.

S-87415 - MXY- Add Option to Avoid/Award Based on Pairing Check-In Station, With the "If Not" Qualifier

We have added an option to Avoid/Award pairings based on the Pairing Check-in Station, with the “if not” qualifier available only for Award bids. This is applicable to both Pilots and Flight Attendants.

Note: This is a configuration only, thus requires an upgrade Configuration spreadsheet.

Acceptance Criteria:

GIVEN - a MXY Bidder

WHEN - viewing the bid options

THEN - the option to avoid/award based on the Pairing Check-in Station is visible, with the “if not” qualifier on Award Bid only.

S-93070 - POE - Zero Awards Got Skipped and Not Showing in the Export Report with SDO

We have improved the scheduling process so that if a crewmember is not assigned a schedule by the scheduler, SDO will not be populated on all blank days.

Acceptance Criteria:

GIVEN - a POE schedule run

WHEN - a crewmember does not have a schedule assigned by PBS

THEN - SDO on all blank days does not appear.

S-83277 - HAL/HALC - Incorporating NKS Unstacking Statistics

We enhanced the functionality of HAL’s Unstacking Report for Flight Attendants and Pilots by incorporating Unstacking Statistics. This aligns with the configuration used by NKS. Note: This update introduces a new configuration to HAL’s Unstacking Report (FA's & Pilots).

Acceptance Criteria:

GIVEN - a HAL Admin

WHEN - viewing the Unstacking Report

THEN - the enhanced unstacking statistics following NKS' configuration can be seen

and

GIVEN - a HALC Admin

WHEN - viewing the Unstacking Report

THEN - the enhanced Unstacking Statistics following NKS' configuration can be seen.

S-87251 - UCA - Mixed Line Proration Table (Pilots and Flight Attendants)

We enhanced the configuration of reserve rules by introducing a mixed line specific proration table under Configuration > Rules > Reserve-TotalDaysOff. This is similar to the existing RBP configuration (shown in below image).

The new tables are: Mixed30_Default and Mixed31_Default, and use the same values as the Pairing-DomicileRestWithTable rule (specifically, tables 30_Default and 31_Default, which start with 12).

Note: This update requires an upgrade script, updates to the configuration spreadsheet, and updates to the rule reference manual.

Acceptance Criteria:

GIVEN - a UCA Admin

WHEN - reviewing the Rule Editor

THEN - the new parameters: Mixed30_Default, Mixed31_Default display

and

WHEN - completing a Scheduler run

and

WHEN - processing reserve for a crewmember who received a mixed line

THEN - the Scheduler uses the new proration table.

S-87253 - UCA - UCA Change to Consecutive Reserve and Mixed Lines (Pilots and Flight Attendants)

We implemented a transition from the Concurrent Reserve module to the Consecutive Mixed Lines module for UCA. This is now the baseline configuration, where the bid configuration uses a simple Reserve Bid Group along with Mixed Line Bid Groups.

Also, to enhance reporting, Mixed Line statistics (eight items) have been added to the statistics report, Dynamic Statistics Report (eight items), and the Quick Statistics window (lower left window, two items). Consecutive reserve statistics (two items) have also been added into the Unstacking Report.

For this enhancement, an upgrade script is required. Upon upgrade, all users’ default and current bids for the current period are cleared/wiped. These bids are then converted into the Consecutive Mixed Line format using system-generated bids only. The upgrade also automatically sets UCA to Consecutive Mixed Lines for the current active period.

Acceptance Criteria:

GIVEN - a UCA system

WHEN - the system is upgraded

THEN - all users’ default and current bid for the current period are cleared/wiped and turned into the Consecutive Mixed Line format using system-generated bids only

and

WHEN - the system is upgraded

THEN - the Consecutive Reserve Mixed Line Module displays in the General Tab

and

WHEN - a Bidder is bidding

THEN - the Mixed Line Bid Groups can be added

and

WHEN - runs have been completed

THEN - the Mixed Line Stats are visible in the Statistics, Dynamic Statistics and the Quick Statistics Window

and

WHEN - runs have been completed

THEN - the Consecutive statistics are visible in the Unstacking Report.

S-87264 - UCA - Coloring Long Call Reserve

We have enhanced the Reserve Bid options by introducing the ability to bid for both Long Call and Short Call—referred to as “BOTH”. This feature is now required for both Pilot and Cabin crew as per UCA, therefore the new bid option has been added to all three bid configuration sets: UCA-Pilot-C-Config, UCA-Pilot-F-Config, and UCA-Cabin-Config.

In addition, we have added configuration for post-process reserve coloring. The following settings have been updated:

PbsSettings.xml:

ReserveBlockColouring-Policy=CallType
ReserveBlockColouring-AllowLongCallForMixedLines=1 (True)-->confirmed with UCA and YES to Long Call (this is taken to mean YES to "AllowLongCallForMixedLines").

UserTypeOptions.xml:

Add ConfigReserveTab Permission ENABLE (for Scheduler UserType only)
Add RunTemplateReserveCallTypeColouring Permission ENABLE (for Scheduler UserType only).

Report templates have also been updated. Both the Statistics Report and the Dynamic Statistics Report now display Reserve Call Type statistics.

Note: Upgrade to the Configuration spreadsheet is required.

Acceptance Criteria

GIVEN - a UCA Admin

WHEN - launching a run

THEN - the run parameters for Reserve Coloring (sections for Short Call Types & Long Call Types) displays.

GIVEN - a UCA Admin

WHEN - viewing the Statistics Report

THEN - the number of lines for each Call Type, and the ReserveCallTypeCoverage table with Short Call Items displays.

GIVEN - a UCA Admin

WHEN - viewing the dynamic stats report

THEN - the number of lines for each Call Type, and the Reserve Coloring Grid displays.

GIVEN - a UCA Bidder

WHEN - in a Reserve Bid group

THEN - the option for Short and/or Long Call Reserve displays.

S-94181 - VXP - Pairing Start Station YES Flight Attendants and Pilots

For VXP, we implemented the Pairing Start Station feature for both Pilots and Cabin crew. This enhancement ensures that the Pairing Start Station setting is turned on (YES) for both the VXP-Pilot and VXP-Cabin configuration sets.

For instance, we have changed vxp/CategoryOptions.xml in ten places within AwardPairings and AvoidPairings PairingProperties (for both Current and Default bids), as well as within the Filter PairingProperties.

Note: Upgrade to the Configuration spreadsheet is required.

Acceptance Criteria:

GIVEN - a VXP Cabin or Pilot bidder

WHEN - viewing/editing an Award/Avoid pairings bid, or using the pairing search feature in the Bid UI

THEN - the Pairing Start Station property displays.

S-94182 - VXP - Position Bidding Preference YES Flight Attendant Only

For VXP, we implemented the Position Bidding Preference feature, enabling this option specifically for Cabin crew only in the VXP-Cabin configuration set.

Example

As a... ← VXP Planner

I want... ← to have Position Bidding Preference turned on (YES).

The necessary updates were made in vxp/CategoryOptions.xml, across five locations within AwardPairings and AvoidPairings PairingProperties (for both Current and Default bids), as well as within the Filter PairingProperties. This enhancement also includes the LeftToRightPairingPositions sub-option, consistent with other ALCs.

Note: Upgrade to the Configuration spreadsheet is required.

Acceptance Criteria:

GIVEN - a VXP Cabin Bidder

WHEN - viewing/editing an Award/Avoid pairings bid, or using the pairing search feature in the Bid UI

THEN - the Position property displays.

S-87566 - SCX - Add Max Above to the Configuration

We enhanced the bidding functionality for SCX by adding the “Max Above” bid option to the configuration. This update aligns SCX with FTT and JBU, which already have this configuration. The "Max Above" category option is now available for both Current and Default bids.

Acceptance Criteria

GIVEN - a SCX Bidder

WHEN - bidding for Reserve

THEN - the “MaxAbove” bid option in the Current and Default bid tabs displays.

S-87865 - SCX - Incorporating NKS Unstacking Statistics

We enhanced the functionality of SCX’s Unstacking Report for Pilots by incorporating Unstacking Statistics, following the configuration used by NKS.

Note: This enhancement introduces a new configuration to SCX’s Unstacking Report.

S-94779 - [ENABLER] Externalize API Credentials

We enhanced the security and flexibility of the PBS code base by externalizing previously hardcoded N-OC API credentials (Raido, ClassApi...). The relevant code sections, including N-OC (Raido) API and ClassAPI integrations are now externalized and updated to read API credentials from the NAVNWSParams.xml file rather than from hardcoded values.

The system installation path for the N-OC (Raido) API and ClassAPI, including credentials, is now in /navtech/parm/NAVNWSParams.xml. These parameters are accessed using the common module <Core/Utils/NAVNWSParams.h>. The following XML markups have been added:

<RAIDO_API_URL>http://raido.aviolinx.com/api/</RAIDO_API_URL>

<RAIDO_API_PORT> 443 </RAIDO_API_PORT>

<RAIDO_API_CERTPATH>/navtech/parm/ca-bundle.crt</RAIDO_API_CERTPATH>

<RAIDO_API_USERNAME>xxxxx</RAIDO_API_USERNAME>

<RAIDO_API_PASSWORD>xxxxx</RAIDO_API_PASSWORD>

The PBS integration code (in PBS/code/pbsintegration/raido/source/RaidoServices.cpp) now uses member variables instead of hardcoded values, and reads these settings (parameters) when the program starts.

Note: Details about this functionality can be found in the document “what are the parameters name and how to set them up.”

Acceptance Criteria:

GIVEN - a PBS deployment includes an external N-OC API with specific credentials

WHEN - the API credentials are configured in the /navtech/nav/parm/NAVNWSParams.xml file

THEN - the PBS app can connect to the external N-OC API

and

THEN - the PBS app can perform an N-OC Import.

Related Articles