N-PBS 25.5 Enhancements

Modified on: Tue, 23 Sep, 2025 at 3:01 PM

S-92713 - COMMUNITY - Remove Delete Button in Admin UI

Description

We are making a small update to improve the user experience on the Pairings Details tab. The "Delete" button is removed because NAVBLUE’s system, N-PBS, does not allow for the removal of pairings. This change will prevent users from seeing a button that does not actually work, making the interface cleaner and easier to use.

Acceptance Criteria

GIVEN - as Admin/ Scheduler

WHEN - I open tab "Pairings" sub-tab the "Pairings Details"

THEN - I do not see a "Delete" button

S-95407 - COMMUNITY - Rule Editor Ability to Switch Rules Off - Part 1 (Add Parameter)

Description

We are adding a new feature that lets us turn rules on or off directly in the Rule Editor. This is "Part 1" of the project and involves adding a new parameter called "IsActive" to all relevant rules.

How It Works

A new "IsActive" checkbox appears in the Rule Editor for most rules. This allows us to quickly deactivate a rule without having to delete it entirely.

What Rules Are Affected?

The "IsActive" parameter included are the following rule types:

Pairing, Reserve, and Training rules
Rules with no RuleMode
Rules with "Remove" or "Add" RuleMode
The parameter is not added to rules with a "Modify" RuleMode.

Technical Details

This update requires a script to be run that automatically adds the new "IsActive" parameter to all existing rules that need it. In the future, the system will automatically enforce that all new rules include this parameter (unless they are "Modify" rules), which is checked during the build process to ensure everything works correctly.

This change is not reflected in NAVBLUE’s configuration spreadsheets or documentation to prevent the addition of excessive rows. Instead, all new rules include the "IsActive" parameter by default.

Acceptance criteria

GIVEN - an Administrator using the Admin UI

WHEN - the Rule Editor is viewed

THEN - I will see the new "IsActive" parameter (boolean parameter, initially set to 1) for all rules, except those with RuleMode "Modify". So:

including Pairing Rules
including Reserve Rules
including Training (a.k.a. "Event") Rules
including rules with no RuleMode
including rules with RuleMode "Add"
including rules with RuleMode "Remove"
EXCLUDING rules with RuleMode "Modify"

S-96663 - COMMUNITY- Rule Editor Ability to Switch Rules Off - Part 2a UI Editing Details

Description

Make "IsActive" Parameter Editable.

This is "Part 2b" of the project and focuses on updating the Scheduler/LineSimulator to recognize the "IsActive" parameter. This enhancement must be completed after "Part 1" (S-95407), which added the parameter itself.

How It Works

The "IsActive" parameter appears as a checkbox in the Rule Editor for most rules. When a rule is not active (i.e., the box is unchecked), its text turns red to make it stand out.

The "IsActive" checkbox behaves like other parameters:

If a rule is waivable, the "IsActive" parameter is also not editable.
If a rule's parameters are configured to show on the run parameters screen, the "IsActive" parameter is not editable as well.

Compulsory Rules

The following compulsory rules can not be deactivated, and their "IsActive" parameter are permanently not editable:

Pairing-Overlap
Event-Overlap
Reserve-TotalDaysOff
Reserve-TotalDaysOnUsingCreditProration
Reserve-MinDaysOn
Reserve-MaxDaysOn
Reserve-MinDaysOff

Acceptance criteria

GIVEN - an Administrator using the Admin UI

WHEN - the Rule Editor is viewed (and the "IsActive" parameters are already visible (from earlier completed story))

THEN - the parameter "IsActive" is editable (similar to other boolean parameters, using a check-box, when a rule is selected and the "Edit" pane is used) for rules that are not specifically excluded from this ability.

Note: See later acceptance criteria.

AND

WHEN - the "IsActive" parameter is changed to 0 (meaning false) and saved

THEN - the text of "IsActive = 0" shows in red.

GIVEN - a rule where the other existing parameters are not editable, due to the rule being waivable

WHEN - Edit is attempted

THEN - the "IsActive" parameter are similarly not editable

GIVEN - a rule which has any parameters which are not editable because they show on the run parameter screen

WHEN - edit is attempted

THEN - the "IsActive" parameter are similarly not editable for this rule.

Note: Some other parameters may still be editable, but we do not want IsActive to be allowed to be edited for any rule where at least one parameter is overridable in the run parameters screen.

GIVEN - a rule from the list of compulsory rules below:

Pairing-Overlap
Event-Overlap
Reserve-TotalDaysOff (compulsory to have one of these two rules **)
Reserve-TotalDaysOnUsingCreditProration (compulsory to have one of these two rules **)
Reserve-MinDaysOn
Reserve-MaxDaysOn
Reserve-MinDaysOff

WHEN - edit is attempted

THEN - the "IsActive" parameter is not editable

S-96664 - COMMUNITY- Rule Editor Ability to Switch Rules Off - Part 2b Scheduler/LineSimulator

Description

Make "IsActive" Parameter Editable.

This is "Part 2b" of the project and focuses on updating the Scheduler/LineSimulator to recognize the "IsActive" parameter. Note: This work must be completed after "Part 1" (S-95407), which added the parameter itself.

How It Works

The "IsActive" parameter appears as a checkbox in the Rule Editor for most rules. When a rule is not active (i.e., the box is unchecked), its text turns red to highlight it.

The "IsActive" checkbox behaves like other parameters:

If a rule is waivable, the "IsActive" parameter is not editable.
If a rule's parameters are configured to show on the run parameters screen, the "IsActive" parameter is not editable as well.

Compulsory Rules

The following compulsory rules can not be deactivated, and their "IsActive" parameter is permanently not editable:

Pairing-Overlap
Event-Overlap
Reserve-TotalDaysOff
Reserve-TotalDaysOnUsingCreditProration
Reserve-MinDaysOn
Reserve-MaxDaysOn
Reserve-MinDaysOff

Acceptance criteria
GIVEN - the line simulator (which is only available for Pairing Rules) is being used

WHEN - rules are checked

THEN - the line simulator will not use rules that are currently not active (i.e. with "IsActive = 0")
GIVEN - a scheduler run

WHEN - rules are being checked

THEN - the scheduler will not use rules that are currently not active (i.e. with "IsActive = 0")

S-95672 - COMMUNITY - Rule Editor to Show Rules with No Parameters

Description

To improve the Rule Editor's user experience, we are making a few changes.

We will now display all rules in the Rule Editor, including those that do not have any parameters. For these rules, the "Params" column will show an empty cell.

Additionally, the "Edit" button are grayed out and made not active for any rule that has no parameters to prevent confusion and errors. This will make it clear that there's nothing to edit for that specific rule.

Acceptance criteria

GIVEN - a PBS admin

WHEN - viewing the Rule Editor window

THEN - all rule names that have no params are displayed in the list

AND

WHEN - viewing a rule with no parameters

THEN - the edit button are greyed out

S-96494 - Community - Show Validation Error on Copy & Paste of Bid Lines in the Inadequate Time Range

Description

We are enhancing the copy-paste feature for bid lines to make it more intuitive.

Problem: Currently, when you try to paste a bid line that's from a different time period, the system silently fails without any explanation.

Solution: We are adding a new feature that provides a clear error message. This message will tell you exactly why you can not paste your selection, making the system more user-friendly.

How It Works

Error Display: An error message appears when you try to paste data that is invalid, such as a time range outside of the acceptable period. It will also appear if you copy valid data but then switch to a different tab where that data is not valid to be pasted.
Error Removal: The error message will disappear on its own when you either switch to a different tab where the data is valid to be pasted or when you copy new data to your clipboard that meets the validation criteria.

This update applies to the Award, Avoid, and Prefer Off bid lines.

Acceptance criteria

GIVEN - as a Bidder

WHEN - I want to copy-paste in the inadequate time range

THEN - I will get an error message: Paste disabled: Award/Avoid/ Prefer Off + Departing On/ Duty On/ Check -In time - depends on the bid type + Date/Date Time Range/ Check In etc. + is out of the bid period.

S-97211 - COMMUNITY - Clean Up Unused Vacation GDO Functionality

Description

We are removing the duplicate Vacation GDO and Automatic Vacation GDO options from the PbsSettings under "Configuration." These will now only exist under the CustData section, which is their correct and intended location. The system's code (including the WebApp and Scheduler) are updated to read these settings exclusively from CustData.

We are also simplifying the available options for Vacation GDO:

Replacing Options: We are replacing the four old options (InnerAbsenceCode, OuterAbsenceCode, InnerDays, and OuterDays) with just two new options (AbsenceCode and Days). The code are adjusted to use the new options and will no longer reference the old "Outer" options.
Removing Redundant Options: We are permanently removing the BidOnlyInsideCurrentPeriod and TreatEachAbsenceAsSeparateBlock options. No customers were using these, and the system's underlying code will now behave as if both of these options were set to their default states (true and false, respectively). This simplifies the user interface and removes unnecessary complexity.

Acceptance criteria

GIVEN - a customer using Vacation Extension (a.k.a. Vacation GDO) - i.e. JZA (since they are the only customer currently using it)

WHEN - a person is looking at the PbsSettings.xml file and the Configuration Spreadsheet

THEN - they will only see VacationGDO options under "CustData", and they will no longer see those options under "Configuration"

GIVEN - a customer using AutomaticVacationGDO - i.e. POE or CJT

WHEN - a person is looking at the PbsSettings.xml file and the Configuration Spreadsheet

THEN - they will only see AutomaticVacationGDO options under "CustData", and they will no longer see those options under "Configuration"

GIVEN - a customer using Vacation Extension (a.k.a. Vacation GDO) - i.e. JZA (since they are the only customer currently using it)

WHEN - bidding for Vacation Extension (in both pairing and reserve bid groups)

THEN - bidding will continue to work correctly, including taking account of the config options:

"VacationLength" (a vacation block must be at least this length in order to qualify for Vacation GDOs)
"AbsenceCode" (to recognize pre-awarded GDOs already next to vacations)
"Days" (to recognize how many Vacation GDOs can be bid-for in association with a qualifying vacation block)

GIVEN - a customer using Vacation Extension (a.k.a. Vacation GDO) - i.e. JZA (since they are the only customer currently using it)

WHEN - the scheduler is processing a bid group with a Vacation Extension bid (in both pairing and reserve bid groups)

THEN - processing will continue to work correctly, including taking account of the config options:

"VacationLength" : a vacation block must be at least this length in order to qualify for Vacation GDOs.
"AbsenceCode" : to recognize pre-awarded GDOs already next to vacations, and to use this code for the new Vacation GDO absences awarded by the run.
"Days" : to recognize how many Vacation GDOs can be awarded in association with a qualifying vacation block.

GIVEN - a customer using AutomaticVacationGDO with the Waive bid - i.e. POE

WHEN - bidding for Waive Vacation GDO (in both pairing and reserve bid groups)

THEN - bidding will continue to work, allowing the bidder to waive Vacation GDO dates.

Note: detailed testing of Automatic Vacation GDO functionality is not required for this story, since the only change for this is the location of the config options, so just verifying that the waive Vacation GDO bid still works in at least one case is sufficient.

GIVEN - a customer using AutomaticVacationGDO with the Waive bid - i.e. POE

WHEN - the scheduler is processing a bid group with a Vacation Extension bid (in both pairing and reserve bid groups)

THEN - processing will continue to work, including awarding automatic vacation GDOs in some cases, and not awarding them in cases where the waive bid has been used.

Note: detailed testing of Automatic Vacation GDO functionality is not required for this story, since the only change for this is the location of the config options, so just verifying that the waive Vacation GDO bid still works in at least one case is sufficient.

S-90599 - COMMUNITY - Copy & Paste from Previous Bid Periods

Description

We have implemented a feature where you will no longer be able to copy data from a previous bid month and paste it into the current one. This change applies to the "Prefer Off" feature, and it mirrors the existing behavior for Awards and Avoids.

For example, if the current bid month is December 2024, you are not able to copy a bid from November 2024 and paste it into the current bid.

The system will now handle this by:

Making the paste button not active
Not displaying an error message

This makes the user interface consistent and prevents outdated information from being accidentally used in a new bid period.

Acceptance criteria

GIVEN - an ALC bidder
WHEN -copy and pasting a Prefer off bid line from the default bid tab with a date that is NOT in the current bid period
THEN - I can not paste the improper date to the current bid period

S-92715 - COMMUNITY - Extension to the Delete Button Functionality with Prepared and Non-Active Periods

Description

To improve NAVBLUE’s system, we are adding the ability to delete and re-create a period if it was set up incorrectly.

The new delete option allows Administrators to remove periods that are not yet active or have not been deactivated. This allows for the correction of any mistakes made when setting up the period's name or dates.

How It Works

Navigate to the Periods tab in the Admin UI.
Select the period you need to correct.
Click the new "Delete" button.
If the period is eligible for deletion, a confirmation message appears: "Are you sure you want to delete the period '[period_name]'?"
After deleting the incorrect period, you can add a new one with the correct details.

Restrictions and Messages:

You can not delete a period that is currently active or deactivated.
If you attempt to delete an active period, the system will display a warning: "Deleting an active period is not allowed."
If you attempt to delete a deactivated period, the warning is: "Deleting a deactivated period is not allowed."

This change ensures that you can easily fix errors in a period's setup without affecting live data.

Acceptance criteria

GIVEN - as Admin/ Scheduler

WHEN - I create a period incorrectly (prepared or non active)

THEN - I can delete it with delete

AND

THEN - Create a new one with proper name/dates

GIVEN - as Admin/ Scheduler

WHEN - delete the activated period

THEN - I can see the popup warning message

GIVEN - as Admin/ Scheduler

WHEN - delete the deactivated period

THEN - I can see the popup warning message

S-94416 - COMMUNITY - Ground Activity - Sit vs Split Duty

Description

This work focuses on fixing a specific issue with how NAVBLUE’s system, CrewTrac, interprets ground activity. Currently, when a pilot has a dayroom, the system sometimes misreads it as two separate, overlapping duties. This happens because two records with the same time are incorrectly treated as distinct events.

The goal is to update the system to correctly identify a dayroom and not confuse it with two separate duties.

What is Changing?

The primary changes are in the CrewTracPairingContainer.cpp file, which handles the conversion of raw data. We will add new logic to:

Detect a Dayroom: The codes are updated to check for specific hotel information and look for two records with identical timestamps to correctly identify a dayroom.
Modify ConvertRawRecordToConverted: The function that converts data are updated to properly handle these dayroom records.
Update AssignStationsToDuties: We will ensure that the correct start and finish locations are assigned to duties, even when a dayroom is included.

Technical Impact

This change is limited to the CrewTracPairingContainer.cpp file and only affects how we import data from CrewTrac files. There are no changes to the database or the user interface.

Acceptance criteria

GIVEN - a UCA Admin

WHEN - iImporting a pairing with a day room

THEN - layover info (Location, Duration, Hotel etc.) not displayed on the report

S-95793 - JBU - Future Absence File

Description
To fix an issue where an absence file is being rejected because it contains data for the next month, we need to update the system to correctly handle absences that extend into the future.

Currently, the system is designed to reject an absence that goes into a period for which a schedule does not yet exist. However, the system is supposed to accept absence data for the past, present, and future (up to three months of data in the file). We will adjust the logic so that the system is "happy" with a future absence as long as the next period has been created, even if it has not been fully prepared yet.

This change will resolve the error and it allows for the proper handling of future absence data.

Acceptance criteria

GIVEN - a JBU file

WHEN - absences that carry over into the future

THEN - the file should load

S-96318 - ACA - Any Category is set to 99999, unless changed by the Admin

Description
We have added a new setting to categories called "BiddingThreshold." This feature is only for ACA Administrators.

When you edit any category, you'll see a new option to set a bidding threshold value. By default, this value is set to 99999 for all categories. You can change it to any value between 0 and 99999.

Acceptance criteria

GIVEN - an ACA Admin

WHEN - a category threshold is not set
THEN - it will automatically be set to 99999

WHEN - the upgrade script is run

THEN - all categories are set to 99999

S-93649 - ACA - Change P to SD

Description

We are updating all instances of the "P" crew classification to "SD". This is a system-wide change that will affect the following:

Existing Categories: All current "P" categories are converted to "SD" categories.
System Files: We will update the BaseCrudInfo.xml, PBS Settings.xml, RuleConfig.xml, and CategoryOptions.xml files to reflect the new "SD" classification.
Database: Scripts are run to update all existing "P" crew classifications to "SD" in the database.

This change ensures a consistent and standardized classification system across all areas of the platform.

Acceptance criteria

GIVEN - ACA Admin

WHEN - viewing the Config Categories

THEN - the crew classification from P to SD

AND

THEN - the position within the classification from P to SD

AND

THEN - all existing P categories will change into SD categories

GIVEN - ACA Bidder in the SD category

WHEN - viewing bid options

THEN - I will see the normal bid options

GIVEN - ACA Admin

WHEN - I do a sequence of runs:

SD pairing run
SD reserve run
FA pairing run
FA reserve run

THEN - all the runs will complete successfully

S-93651 - ACA - Seniority Number Cut Off by Category - Admin UI Config

Description

We have added a new setting to categories called "BiddingThreshold." This feature is only for ACA Administrators.

When you edit any category, you'll see a new option to set a bidding threshold value. By default, this value is set to 0 for all categories. You can change it to any value between 0 and 99999.

This change requires a script to be run to update all existing categories and are documented in the configuration spreadsheet.

Acceptance criteria

GIVEN - a ACA Admin
WHEN -editing a category, you will then see the new option to set= "BiddingThreshold"
THEN - we are able to change the value from any number from 0-99999

AND

WHEN -I set a value in a category and log out of the system
THEN - upon re log in my value I set is the same

S-94020 - ACA & RGA - Cosmic CityPair Restrictions New Global Rule (Cosmic Options)

Description
We have implemented a new global rule called CosmicOptions are implemented. This rule will only be visible to customers ACA and RGA.

This rule will have one parameter called CityPairs, which allows Administrators to define specific city pairs (e.g., YYZ-AMS, AMS-YYZ, YYC-SYD, SYD-YYC). The functionality is similar to how the CaribbeanOptions rule works for RGA.

Acceptance criteria

GIVEN - a ACA & RGA admin
WHEN - viewing the Global rules
THEN - I will see the new option called CosmicOptions with the parameter CityPairs.

Starting examples: YYC-LHR, LHR-YYC, YUL-BCN, BCN-YUL, YUL-BRU, BRU-YUL, YUL-CMN, CMN-YUL, YUL-DEL, DEL-YUL, YUL-FCO, FCO-YUL, YUL-FRA, FRA-YUL, YUL-GVA, GVA-YUL, YUL-LHR, LHR-YUL

GIVEN - a non ACA & RGA admin
WHEN - viewing the Global rules
THEN - I will not see the new option called CosmicOptions with the parameter CityPairs

S-93903 - ACA & RGA - Absence File Import

Description

We are updating the system to give you more control and precision when importing absence data.

What is New

We are introducing a new file import option called "JCT Absences." This new functionality separates the import of absence data from the employee data import.

How It Works

You will now be able to import employee data and absence data as two separate files.
This new process requires you to import employee data first.
The system will prevent the import of absence data if the employee information for that period has not already been successfully loaded.

This change ensures a more structured and accurate import process, as the absence importer will now follow a dedicated schema and validation process.

Acceptance criteria

GIVEN a ACA & RGA Admin

WHEN -required crew members have been successfully imported

AND

WHEN -I click on import and select the "JCT Absences" file

AND

WHEN -a proper file with proper data is imported
THEN - the file should be imported into the system without an error

AND

THEN - the column "JCT Absences" should be updated to reflect the results of the import (should turn green)

GIVEN - an ACA & RGA Admin

WHEN -no crew members have been imported

AND

WHEN -I click on import and select the "JCT Absences" file

AND

WHEN - the import concludes

THEN - warning messages should appear saying that the system was unable to import the absences

S-93781 - ACA & RGA - Award File Export

Description

We are making several updates to the award export functionality to provide more comprehensive and organized data.

What is New

Single Export File: The system will now generate a single file that contains both reserve and pairing awards, simplifying the export process.
Updated File Naming:
- The "Award Detail" file will now include all activities in the block, including Training activities.
- The "Award Master" file will contain the employee number and block number.
Data Formatting:
- The format for a specific identifier (the "OA" field) is being updated from a three-digit code to a ten-digit code.
- Reserve items that are longer than 24 hours will now be broken down into multiple, separate 24-hour blocks for a more accurate export.
New Admin UI Feature:
- A new "Export" button is added to the Admin UI, giving you a direct way to generate these new files.

Acceptance criteria

GIVEN - ACA & RGA Admin

WHEN - exporting a Award Detail File

THEN - all activities in that awarded roster month including training activities will show

GIVEN - a ACA & RGA Admin

WHEN - exporting a Award Master File
THEN - I will see the employee numbers and block numbers in the file

S-94644 - ACA & RGA - Change Absence Code Field from 6 Character to 10

Description

We are making a small update to how absence codes are imported.

Updating Absence Code Import

The system's importer is being updated to read a new, longer absence code. Previously, the system could only accept a six-character absence code. Now, it is able to read and process codes that are up to ten characters long.

This change will ensure that historical pairings files from ACA and RGA will import successfully without any issues.

Acceptance criteria

GIVEN - ACA & RGA Admin

WHEN - Importing the historical pairings file (ACA History) with ten characters

THEN - The import shall be successful

S-93901 - ACA & RGA - Crew File Import

Description

We are introducing a new file import option called "JCT Crew". This new functionality separates the import of employee data from the absence data import.

How It Works

You will now be able to import employee data and absence data as two separate files. This new process requires you to import employee data first.

The system will prevent the import of absence data if the employee information for that period has not already been successfully loaded. This change ensures a more structured and accurate import process, as the crew importer will now follow a dedicated schema and validation process.

Acceptance criteria

GIVEN a ACA & RGA Admin

WHEN -I click on import and select the "JCT Crew" file

AND

WHEN -a proper file with proper data is imported
THEN - the file should be imported into the system without an error

AND

THEN - the column "JCT Crew" should be updated to reflect the results of the import (should turn green)

S-94326 - ACA & RGA - Upon Import, Set the CosmicResctricted Flag for

Specified People

Description

We are adding a new feature to manage crew members who may have restrictions related to cosmic radiation.

What is New

During the crew member file import, the system will now check for a new Cosmic Restricted flag. This flag is a True or False value in the Crew Member Details file.

If a crew member's flag is set to True, they are restricted from flying specific city pairs.
The list of these restricted city pairs can be easily managed and updated in a separate table within the admin section.

Acceptance criteria

GIVEN - A ACA/RGA crew member

WHEN - being imported with a boolean "true"

THEN - in the admin ui the check box is marked on CrewRestrcited

GIVEN - A ACA/RGA crew member

WHEN - being imported with a boolean "false"

THEN - in the admin ui the check box is marked not on CrewRestrcited

Note: The following is not really testable as no other airline is configured to have Cosmic Restricted show up on the UI and no other airline is configured to import this file type.

GIVEN a NON ACA/RGA crew member
WHEN -being imported the boolean value should always read false
THEN - when I go to the admin UI nothing is checked

S-94502 - ACA Integration - Location Group Restriction ie: ZIKA, Countries, Etc.

Description

We are updating the crew member import process which allows the automatic application of location-based restrictions.

What is New

Crew planners will now be able to include two new fields in the crew member import file: "RestrictedLocationGroup" and "Country Restrictions."

When you import the file, the system will read the names of the specified location groups and automatically apply those restrictions to the corresponding crew members. For example, if you list "Europe" as a restricted location group for a crew member, the system applies all rules and limitations associated with that group. This will replace the older "Tags" field with the more specific "RestrictedLocationGroups" field.

Example:

"restrictedLocationGroups": ["ZIKA", "COVID", "ABCD", "LMNO"] ect....
"countryrestrictions": ["India", "Brazil"] ect....

Acceptance criteria

GIVEN -A ACA Admin

WHEN - when importing a file with "locationGroupRestrictions"

THEN - they are imported with the correct location group restrictions

AND

WHEN -importing a file with "country Restrictions"

THEN - they are imported with the proper location group restrictions

S-94324 - ACA/RGA - Add a Crew Member Flag Cosmic Restricted (New Database Field on PersonPeriod) & Admin UI

Description

We have added a new flag for crew members called Cosmic Restricted.

This new Cosmic Restricted flag is a simple yes/no (Boolean) field. It is added to the crew member's information in the database and is visible on the Admin UI for ACA and RGA. You'll find it with the other Boolean fields on the user interface.

Acceptance criteria

GIVEN - a ACA & RGA Admin

WHEN - viewing a crew member

THEN - I will see the check box field for CosmicRestricted

GIVEN - a non ACA & RGA Admin

WHEN - viewing a crew member

THEN - I will not see the check box field for CosmicRestricted

GIVEN - a ACA & RGA admin

WHEN - I make a change to the cosmic restricted check box and save my changes
THEN - when I log out and back in my changes will have saved/stayed the same

S-94327 - ACA/RGA - Scheduler to Enforce Cosmic Restriction

Description

We have implemented a feature that if a crew member is flagged as cosmic restricted, the scheduler will not allow them to be awarded any pairings that are also flagged as cosmic restricted.

How It Works

A pairing is considered cosmic restricted if any of its legs—including deadhead (DH) legs—matches a city pair on the restricted list.

If a trip is not awarded to a crew member due to this rule, the system will provide a new reason in the bid results: "Cosmic Restricted."

This feature does not include "unstacking" functionality, which would otherwise allows the system to try different combinations to fit the pairing. This means the restriction is a direct and final reason for the un-awarded pairing.

Acceptance criteria

GIVEN - a ACA/RGA scheduler run

WHEN - a crew member bids for a pairing in which any leg matches a cosmic city pair and the crew member is flagged as cosmic restricted
THEN - the CM is not awarded this pairing

AND

THEN - the reasons report will show "Cosmic Restricted"

S-94878 - ACA/RGA - Training Export

Description

Name of File: Training Detail (contains all training activities)

.csv format

Acceptance criteria

GIVEN - ACA Admin

WHEN - When exporting a Training Detail File

THEN - All training activities in the roster month will show

S-93891 - ACA - Error Messaging/Pop Up Submission Information

Description

We have implemented a feature based on the seniority threshold set in the Admin UI, your bid will now be submitted for either an SD (Seniority Defined) category or an FA (Functional Area) category.

Bid Submission Logic

If your seniority is above the threshold set in the Admin UI for an SD category, your bid is successfully submitted for both the SD and FA categories. You will receive a confirmation message that includes two confirmation numbers: "SD bid submitted successfully confirmation number XXXXX ; FA bid submitted successfully confirmation number XXXXX."

If your seniority is below the threshold set in the Admin UI for an SD category, your bid will only be submitted for the SD category. Your FA bid is rejected. You will receive an error message that states: "FA bid not submitted, due to SD seniority threshold; SD bid submitted successfully confirmation number XXXXX."

Acceptance criteria

GIVEN a ACA Bidder
WHEN -bidding in a SD category, where the seniority threshold is above the number set in the admin ui
THEN - I will get the message when I try to submit my bid "SD bid submitted successfully confirmation number XXXXX ; FA bid submitted successfully confirmation number XXXXX"

AND

WHEN -bidding in a SD category, where the seniority threshold is below the number set in the admin ui
THEN - I will get the error message when I try to submit my bid "FA bid not submitted, due to SD seniority threshold; SD bid submitted successfully confirmation number XXXXX"

S-93890 - ACA - Read Threshold & Submit or Deny Bid (Current Tab Only) Based on Seniority in Admin UI

Description

We have added a new feature that allows crew planners to set a bidding cutoff by category in the Admin UI.

This feature affects bidders who have both an SD (Seniority Defined) and an FA (Functional Area) seniority number. When a bid is submitted, the system will now check the bidding cutoff that was set by the crew planner in the Admin UI. Based on that threshold, it will determine if both the SD and FA bids should be submitted successfully.

Acceptance criteria

GIVEN a current bid, when a bidder has a SD & a FA seniority number
WHEN -I submit my bids
THEN - based on the threshold set in the admin ui, my bid will either be submitted for a SD category ONLY OR a FA & SD category

AND

WHEN -I submit my current bid
THEN - if my SD seniority number is above the threshold my FA bid is submitted alongside my SD bid

AND

WHEN -I submit my current bid
THEN - if my SD seniority number is below the threshold my SD bid is submitted ONLY and my FA bid is rejected

GIVEN a default bid
WHEN -I submit my bid
THEN - both my SD & FA bids are submitted

S-93904 - ACA - SD/FA Indicator Export

Description

To simplify how awards are identified in the export file, we are making a change for SD crew members.

If a crew member has both an SD and an FA category and is awarded an FA schedule, the export file will now indicate their award with an "A" instead of an "SF". This change only applies to the export file that goes to the DOF system. This means that "SF" is not used as part of the import process.

Acceptance criteria

GIVEN - a admin
WHEN -exporting awards for a SD & FA Qualified crewmember

AND

WHEN -the crew member is awarded a FA schedule
THEN - I will see the "A" identifier in the run export

AND

WHEN -exporting awards for a SD & FA Qualified crewmember

AND

WHEN -the crew member is awarded a SD schedule
THEN - I will see the "SD" identifier in the run export

S-94504 - RGA - Crew Details LD Restriction if Ineligible

Description

We have added a new eligibility setting to the system. This allows Administrators to manage who can be assigned as a Lead (LD). If the new value is set to False, the person is restricted from taking on the Lead role. If the value is True, they are eligible.

Acceptance criteria

GIVEN - A RGA Crew member detail file

WHEN - importing a crew member with a "False" value

THEN - the crew member is restricted from being assigned as Lead (LD) (position restriction for LD)

GIVEN - a RGA Crew member detail file

WHEN - importing a crew member with a "True" value

THEN - the crew member is not restricted from being assigned as Lead (LD) (no position restriction for LD)

S-94879 - RGA - Historical RGA Addition of “C” as a Designator on the Pairing to Indicate Caribbean Crew Rest for Rouge - Scheduler

Description

We are updating how the system identifies a "Caribbean" pairing to make it more accurate and flexible.

How it Works

A pairing will now be flagged as Caribbean if it meets one of two conditions:

It meets the existing criteria (based on locations and minimum duty minutes).

A new Caribbean flag is manually set to true for that specific pairing.

This change means the system will recognize a pairing as "Caribbean" based on either an automated check or a specific flag.

This update affects two existing rules:

"Caribbean Home Rest" (Pairing line rule)
"Rest Between Caribbean Pairing And Event" (Training line rule)
No changes are needed to the rules themselves, as they will automatically adopt the new, updated criteria. The relevant documentation for both rules is updated to reflect this change.

Acceptance criteria

(Automated unit test)

GIVEN - The Pairing-CaribbeanHomeRest rule is being tested

WHEN - A pairing is marked as Caribbean in the database (but does not meet the pre-existing location/MinDutyMinutes criteria for counting as Caribbean)

THEN - The pairing is counted as Caribbean.

The rule applies to it, and the required rest is enforced
Automated unit test

GIVEN - the Pairing-CaribbeanHomeRest rule is being tested

WHEN - a pairing meets the pre-existing location/MinDutyMinutes criteria for counting as Caribbean

THEN - the pairing is counted as Caribbean.

The rule applies to it, and the required rest is enforced)
Automated unit test

GIVEN - the Training-RestBetweenCaribbeanPairingAndEvent rule is being tested

WHEN - a pairing is marked as Caribbean in the database (but does not meet the pre-existing location/MinDutyMinutes criteria for counting as Caribbean)

THEN - The pairing is counted as Caribbean.

The rule applies to it, and the required rest are enforced.
Automated unit test

GIVEN - the Training-RestBetweenCaribbeanPairingAndEvent rule is being tested

WHEN - a pairing meets the pre-existing location/MinDutyMinutes criteria for counting as Caribbean

THEN - the pairing is counted as Caribbean.

The rule applies to it, and the required rest are enforced.

S-94877 - RGA - Historical - Addition of “C” as a Designator on the Pairing to Indicate Caribbean Crew Rest for Rouge (Import)

Description

We are adding a new "C" designator to pairings to indicate that they qualify for Caribbean crew rest.

This change requires a few updates behind the scenes:

Database: A new field is added to the pairing database to store this information.
Import Process: The pairing importer is updated to automatically flag a pairing with a "C" if it meets the criteria for Caribbean crew rest.
Backend: We will update the backend to query this new data and ensure the system correctly applies Caribbean crew rest rules when the "C" flag is present.

An upgrade script is run to implement these database changes.

Acceptance criteria

GIVEN an import file
WHEN -pairings are flagged with "C" to indicate Caribbean crew rest
THEN - database is populated with the data and the import will load successfully

S-84066 - ASAP - New Status: PRBB = i3 Code Update

Description

Updates to Reduced Block Status.

We are updating the system to correctly display the status for pilots flagged with the Reduced Block attribute. This change is being made to support a new program for pilots starting in July 2024.

Currently, pilots with this attribute are being incorrectly assigned the Flight Attendant status of FLBL in the I3 system. We are correcting this so the system assigns the correct status for pilots.

How It Will Work

For Line Holders: If a line holder is flagged as "reduced block," their status will now correctly be exported as PRBB.
For Reserves: If a reserve is flagged with the "reduced block" attribute, their days are not prorated. Their status are exported as PLCR to reflect their regular reserve status, as requested by ASA.

This update ensures that the I3 system accurately reflects the correct status for all pilots based on their reduced block status and role.

Acceptance criteria

GIVEN - an Admin

WHEN - a pilot Crewmember is flagged as reduced block in the details

THEN - I3 should reflect the status of PBRR for Line Holders.

*Currently, the system gives the Flight Attendant status, FLBL, which should not be applied. This needs to be fixed and replaced with the PBRR.

S-96455 - ASAP Non - CQ Change

Description

Following a discussion with ASAP, we are making some updates to how rest periods are calculated around absences. The core change is to standardize rest periods for all WorkForDuty absences.

What is Changing

We are adjusting the required rest time after a non-CQ WorkForDuty absence before starting a new pairing.

Before: Previously, no rest was required after these absences.
After: The new rule will require 720 minutes of rest. This can be reduced to 630 minutes if the "Waive Base Rest" bid is used.

This update ensures all non-CQ WorkForDuty absences, whether they are training-related or not, are treated the same way. The rules for CQ absences and Non-CQ Non-Training Non-WorkForDuty absences will remain the same.

How It Works

To make this happen, we are:

Removing the old rules that handled rest for training absences.
Adding two new rules that specifically apply to WorkForDuty absences.
- The first rule sets the default rest to 720 minutes.
- The second rule, which is activated by the "Waive Base Rest" bid, reduces the rest period to 630 minutes.

This change requires an upgrade script to update the system's configuration files and are documented in the config spreadsheet. We will also run tests to confirm that the new rest rules are correctly enforced and that the "Waive Base Rest" bid works as intended.

Acceptance criteria

GIVEN - an ASAP Admin

WHEN - viewing the Rule Editor

THEN - instead of seeing two instances of Pairing-RestBeforeAndAfterAbsences rule, which look like this before the upgrade:

instead there will now be three instances of the Pairing-RestBeforeAndAfterAbsences rule:

One instance will have CQOnly = 1
- MinutesAfter = 720
- MinutesBefore = 720
- all other parameters 0 (same as now)

Another instance will have WorkForDutyOnly = 1
- MinutesAfter = 720
- MinutesBefore = 720
- BidKey = BaseRest
- RuleMode = Remove, all other parameters 0

Another instance will have WorkForDutyOnly = 1
- MinutesAfter = 630
- MinutesBefore = 630
- BidKey = BaseRest
- RuleMode = Add
- all other parameters 0

GIVEN - an ASAP Admin

WHEN - doing a run and processing a pairing bid group that does not have the "Waive Base Rest" bid

THEN - the system will enforce a rest of 720 minutes after a non-CQ WorkForDuty absence, before a subsequent pairing

(This can be tested by choosing a particular pairing that the person will bid for, and then pre-awarding them a non-CQ WorkForDuty absence before that pairing, with a gap of the amount being tested (e.g. 719 minutes, 720 minutes))

GIVEN - an ASAP Admin

WHEN - doing a run and processing a pairing bid group that has the "Waive Base Rest" bid

THEN - the system will enforce a rest of 630minutes after a non-CQ WorkForDuty absence, before a subsequent pairing

Note: This can be tested by choosing a particular pairing that the person will bid for, and then pre-awarding them a non-CQ WorkForDuty absence before that pairing, with a gap of the amount being tested (e.g. 629 minutes, 630 minutes).

S-90040 DAL - Short Call - Bid UI Display Items

Description

We added a feature so when a user logs into the bidder UIthey will see a tab (just like pairings and training) where they can go and search for specific SC types and add them to the bid tab.

The list view for Short Calls should look like for pairings.

The function "enable bids mode" should stay and work in the same way as for Pairings.

Differences:

There are no possibility to extend the Short Call record because all details are displayed already in the line.
No printer or Report Icon

The Bidder is able to filter records by: Start, Identifier, End, TDA, FRMS:

The record display example:

Acceptance criteria

GIVEN - a DAL Bidder

WHEN - viewing the bidder UI

THEN - I will see the SC (Short Call) tab

AND

THEN - I will see a list of all SC items listed by identifier with start date and time, FRMS and TDA available in the drop down

AND

THEN - I am able to sort SC items by Start, Identifier, End, TDA, FRMS & count

S-90041 DAL - Short Call - Bid UI Filtering - Identifier, FRMS

Description

We have implemented a feature where when you click on the "Short Calls" tab, you are able to sort SC by Identifier, FRMS, TDA = body type (wide or narrow,) Start, End, FRMS status-similar to the pairings tab.

IE:

FRMS:

Identifier:

ICON:

Acceptance criteria

GIVEN - a DAL Bidder
WHEN -I view the SC tab
THEN - I am able to filter SC items by Identifier, FRMS status

GIVEN - a DAL Bidder

WHEN - viewing a short call item from the short call tab
THEN - I am able to add the SC result into my bid with the "enable bids mode"

S-93806 DAL - Short Call - Bid UI Filtering - Start

Description

We have implemented a feature so as a bidder, when you filter SC with Start (Dates List, dates Range, Days of Week List), you are able to check how many records meet the filter conditions.

As well when you click on the "Short Calls" tab, you are able to sort SC by Start -similar to the pairings tab.

IE:

Start:

Date:

Dates List:

Dates Range:

Days of the Week:

Time:

Acceptance criteria

GIVEN - a DAL Bidder
WHEN - I view the SC tab
THEN - I am able to filter SC items by Start

GIVEN - a DAL Bidder

WHEN - viewing a short call item from the short call tab
THEN - I am able to add the SC result into my bid with the "enable bids mode"

S-92736 DAL - Short Call - JSON Format

Description

The system will now include Short Call Period awards in the export file along with other award information. This provides a complete record of all awarded activities.

The export file will now contain new data items for each Short Call award. Each item will include a new indicator for FRMS (Fatigue Risk Management System), which is either "F" or left blank. This allows for quick identification of awards with FRMS implications.

Here's an example of what a Short Call award will look like in the new export file:

ActivityCode: "SC"
StartDateTime: The start date and time of the short call period.
EndDateTime: The end date and time of the short call period.
TotalDaysAvailable: The number of days available for the short call.
FRMSIndicator: "F" if the award has an FRMS flag, or blank if it does not.
ShortCallName: The specific name of the short call.

Acceptance criteria

GIVEN - a DAL JSON export for a concurrent run
WHEN - a crewmember has one or more daily short call item awarded
THEN - I will see new SC items in the award section with the 6 line format within each SC item

S-90039 DAL - Short Call - WebApp Bid by Additional Various Properties UI Bidding Phase Two

Description

New Award Short Call Period Bid Preference

We are introducing a new bid preference that allows you to specify your preferences for Short Call (SC) periods. This preference will have several sub-options to help you find and bid on the exact SC periods you want.

Phase One

In this initial phase, you are able to search for specific SC periods by their number or label and add them to your bid.

Phase Two - Future Enhancements

Future updates will add more filtering options that allows you to be more specific with your bids:

Dates: You'll be able to filter by specific dates, a date range, or by days of the week.
Time: You will have the ability to filter by an exact time, a time before or after a certain point, or within a specific time range.
FRMS Status: You can choose to include or exclude SC periods based on their FRMS (Fatigue Risk Management System) status.
Limiting Awards: A Limit option is added to restrict the number of SC periods you are awarded on a single bid line.

Note: You are not able to bid by Total Days Available (TDA) because your reserve schedule is already built before these preferences are processed. This ensures a streamlined bidding process.

Examples:

Examples of where to find new bid options:

Step 1 (implemented in Phase 1)

Award Short Call:

Options Under "Award Short Call"

Phase 1

"Identifier" with Ordered:

Phase 2

Sub-menu for Award Short Call is extended by FRMS and Limit, Start (with Date, Time):

1. Identifier menu is extended with:

(If or If Not)

Start:

Date:
- Dates should be available as a Dates List, Dates Range, or Days of Week List
- Examples shows below

’

Time:
- Time should be available as Exact, Before, After, or Range. The example below is similar but not an exact one.

2. FRMS status

If or If Not
FRMS ="F" or "" in the file

3. Limit:

Example of total bid with new properties:

Acceptance criteria

GIVEN - a Dal Bidder
WHEN - I select Award Short Call
THEN - I am able to see the "Identifier" Option with If/If Not

AND

WHEN - I select the "Identifier" Option
THEN - I will get a drop-down of all of the Identifiers available for my category

GIVEN - a Dal Bidder
WHEN - I select Award Short Call

THEN - I am able to see the "FRMS" Option with If/If Not

GIVEN - a Dal Bidder
WHEN - I select Award Short Call

THEN - I am able to see the "Start" Option with If/If Not

AND

WHEN - I select the "Start" Option

THEN - I am able to see the Date and Time options

AND

WHEN - I select the "Date" Option

THEN - I am able to see Dates List, Dates Range, or Days of Week List Options

AND

WHEN - I select the "Time" Option

THEN - I will get a drop down with Exact, After, Before, Range

GIVEN - a Dal Bidder

WHEN - I select Award Short Call

AND

WHEN - I select any of the above options (Identifier, FRMS , Start)
THEN - I am able to select a "Limit" for all options added to that bid group

GIVEN - a Dal Bidder

WHEN -I have created SC bid line

THEN - I can edit this bid line

AND

THEN - all details from initial version of the bid line are visible

S-92890 - DAL SC - Reasons Report Phase Two

Description

We are enhancing the system to provide more detailed feedback on why your bids for Short Call periods were or were not awarded. The new system will now show a summary of your bid's outcome, including how many items were awarded and how many were matched.

How It Works

For each bid, you will see a breakdown that explains the outcome. The number of items awarded, plus the number of items that were not awarded (with a reason), will always add up to the total number of items that matched your bid.

For example:

Bid 1: "Awarded: 1, Matching: 6" means one Short Call was awarded, and five others that matched your bid were not. The reasons for the other five are detailed below.

Bid 2: "Awarded: 0, Matching: 10" means no Short Calls were awarded, and all ten that matched your bid were not.

Reasons for Not Being Awarded

The system will now provide specific reasons why a Short Call was not awarded, such as:

Exceeds Maximum Short Call Items: You already have the maximum number of items.

Awarded to a Senior Bidder: A more senior bidder was awarded the item.

Item Overlaps with Another: The item conflicts with another scheduled activity.

Violates Time Off: The award would violate a required time-off period.

Beyond Bid Limit: The award would exceed the specified bid limit.

Important Notes

Ordered Bids: If your bid is marked as "ORDERED," the system will generate reasons as if each preference was a separate bid, but they will still be grouped together for your easy review.

Award Display: The awarded items will not appear under the bid itself but will continue to be listed in their usual location on the reasons report.

Acceptance criteria

GIVEN - a DAL Bidder

WHEN - viewing the Reasons Report
THEN - I will see reasons under the award short call period bids

AND

THEN - The number of items for which a reason is GIVEN plus the number of awarded items, should always equal the number of matching items

AND

THEN - The number of matching items will include EVERY instance of the count: IE: Item has a count of ten will contribute ten to the number matching.

AND

THEN - the "Item overlaps with another" reason are GIVEN both for other instances of the same item which is awarded AND instances of different items on the same day

AND

WHEN - the first reason identified for an item is {each of the list of possible reasons listed in the description} {ONE TEST FOR EACH ITEM}

THEN - I will see the corresponding reason (AS listed in the description)

GIVEN - a DAL Bidder
WHEN - viewing the reasons report and the bid says ORDERED
THEN - we will generate the reasons as if they were separate preference ordered bids

S-95891 - DAL SC - Scheduler Add CoreDailyShortCallProperty Infrastructure

Description

This story is the first in a sequence of updates to the bidding system. It introduces a new concept called CoreDailyShortCallProperty to standardize how the system processes and matches daily short call bids.

What is Changing

We are adding a new class, CoreDailyShortCallProperty, which are the foundational element for daily short call bids. This change makes the short call bidding logic consistent with how the system already handles bids for trips and training.

This update includes the following:

New Property Class: We are creating a new class called CoreDailyShortCallProperty. It will contain a single subclass, IdentifierCdscp, which will hold the specific identifier for a daily short call.
Updated Bid Structure: The existing AwardDailyShortCallCoreHlb are updated. Instead of handling a list of various identifiers, it will now manage a single IdentifierCdscp. This is a preparatory step for future changes that will group multiple properties together.
Code Adjustments: The system's core logic (CoreHlbManager and ReserveCoreHlbVisitor) are updated to handle the new property class. When a bidder places an ordered bid, the system will create a separate AwardDailyShortCallCoreHlb for each ordered item, ensuring that each one is processed correctly.

This initial change is a foundational step that sets the stage for more complex short call bidding features in future updates.

Acceptance criteria

Since this is a scheduler internal task, there is no user-facing change.

GIVEN - a developer doing a Dal run with Daily Short Call, including bids for "If Identifier" with lists of identifiers, with and without "ordered"

WHEN - the same run is done before and after this code change
THEN - the run results are identical (since this is a restructuring of code, but should have the same functionality)

S-95893 - DAL SC-Scheduler add CnfCdscp and DailyShortCallMatcher Infrastructure

Description

This story, which builds on S-95891, focuses on adding the core logic to support bidding for daily short calls. It introduces the concept of a DailyShortCallMatcher, a new tool that will efficiently find short call items that match a bidder's preferences.

What is Changing

We are introducing a new data structure called CnfCdscp, which is a way of logically organizing a bid's short call preferences. This is similar to how the system already handles training and trip bids.

The changes involve:

New Matcher Class: A new class, DailyShortCallMatcher, is created. Its purpose is to quickly and efficiently identify which available daily short call items meet the specific criteria of a bid.
Updated Bid Logic: The system's internal logic for processing bids (ReserveCoreHlbVisitor) is updated to handle the new CnfCdscp data structure. It will collect the daily short call preferences from a bid and organize them into a CnfCdscp that the new matcher can understand.
Modified Data Structures: The underlying data structures is updated to accommodate this new logic, ensuring the system can correctly track and process these preferences.

How It Works

The system will process each bid and build a CnfCdscp that represents the bidder's preferences.
The DailyShortCallMatcher will then use this CnfCdscp to compare the bid against all available daily short call items.
The matcher will return a list of items that match the bid, which the system will then use to determine the final award.

This change is a major architectural update to the bidding and allocation logic, making the system more powerful and capable of handling complex short call bidding rules.

Acceptance criteria

Since this is a scheduler internal task, there is no user-facing change.

GIVEN - a developer doing a Dal run with Daily Short Call, including bids for "If Identifier" with lists of identifiers, with and without "ordered" (but not including bids with "If Not")

WHEN -the same run is done before and after this code change
THEN - the run results are identical.

Since this is a restructuring of code, but should have the same functionality)
Note: Results are not identical for bids including "If Not", since support for that ended up being added under this story, whereas before this story, the "If Not" was ignored.

S-93102 - DAL SC - Scheduler Support Enhanced Identifier Bid Property (with If/If Not)

Description

We are completing the work on the daily short call bidding system by adding support for "If/If Not" conditions. This is the final step in a series of updates to make the bidding process more precise.

How It Works

The system will now be able to handle "If" and "If Not" rules within daily short call bids. This means you can create bids that are contingent on specific conditions, such as bidding for a short call only if it has certain characteristics or if it does not have them.

The underlying code is being updated to recognize and process these new logical conditions. This change ensures that the system correctly interprets and applies your "If/If Not" bids when matching you with available short call periods. This work builds on the infrastructure and data structures that were created in previous updates.

Acceptance criteria

GIVEN a Dal run with Daily Short Call
WHEN -a person has a bid for daily short call if not identifier
THEN - the scheduler will correctly match this bid to other identifiers and award those other identifiers if possible

S-94884 - DAL SC - Submit Phase Two

Description

We have updated the bidding system which allows for more detailed bids on Short Call periods. This change will enable you to submit bids with specific criteria, which will then be visible in the Admin UI.

New Bid Options

The bidding process are expanded to include the following new options for your Short Call bids:

Dates: You are able to specify a list of individual dates, a range of dates, or specific days of the week.
Time: You can now bid for a Short Call at an exact time, before or after a specific time, or within a specific time range.
FRMS Status: You can now bid for Short Calls based on their FRMS (Fatigue Risk Management System) status, using "If" or "If Not" conditions.
Short Call Label: You are able to select specific Short Call periods by their unique number or label.
Limit: You can now use a Limit to restrict the number of Short Calls awarded on a single bid line.

How It Works

The system's core logic are updated to read and process all the details of these new bids. Once a bid is submitted, it is fully visible and manageable in the Admin UI Bid Manager under the bids tab. This ensures that the system correctly processes your detailed bids and that Administrators can view all submitted information.

Acceptance criteria

GIVEN - a DAL bidder
WHEN - submitting a bid, which includes an award daily short call with any of the following syntax's:

Dates List, Dates Range, or Days of Week List, Time=Exact, Before, After, or Range, FRMS status (If or If Not,) SC period number/label (Identifier,) Limit

THEN - the bid will submit successfully

GIVEN a DAL Admin

WHEN -viewing the bid manager for a crew member who has an award daily short call with any of the following syntax's:

Dates List, Dates Range, or Days of Week List, Time=Exact, Before, After, or Range, FRMS status (If or If Not,) SC period number/label (Identifier,) Limit

THEN - I will see the bid with the correct syntax's

S-96380 - DAL Short Call - Generalize CtpDateTimeHelper to CorePropertyDateTimeHelper

Description

We are preparing the system for a new feature by moving a helper class to a more central location.

What is Changing

To support the upcoming "Start On" Daily Short Call Property, we are making the following behind-the-scenes change:

The CtpDateTimeHelper class, which is currently used for training properties, is moved from its old files (CoreTrainingProperties.h and .cpp) to new, more general files: CorePropertyDateTimeHelper.h and .cpp.
We will rename the class to CorePropertyDateTimeHelper to reflect that it can now be used for multiple types of core properties, not just training.
The system's training allocator files are updated to include the new file.

This change is a foundational step that allows the new daily short call feature to use this helper class, making the code more efficient and organized.

Acceptance criteria

GIVEN - a Training run which includes some PatternStart, PatternTouches, EventStart and/or EventTouches CoreTrainingProperties

WHEN -doing the run before and after this change

THEN - the run should behave identically.

It can be verified by comparing scheduler log files.
Note: There are no customer-facing changes for this story, since it is a pure code re-organization story.

S-93104 - DAL Short Call-Scheduler Support FRMS Bid Property

Description

We have added scheduler support for the if/if not FRMS property.

Acceptance criteria

GIVEN - a DAL daily short call run

WHEN - a bidder has an "award daily short call IF FRMS" property
THEN - the scheduler will match the correct items and try to award them to the bidder

GIVEN - a DAL daily short call run

WHEN - a bidder has an "award daily short call IF NOT FRMS" property
THEN - the scheduler will match the correct items and try to award them to the bidder

GIVEN - a DAL daily short call run

WHEN -a bidder has an "award daily short call IF Identifier XXXX IF FRMS" property
THEN - the scheduler will match the correct items and try to award them to the bidder

S-93103 - DAL Short Call - Scheduler Support Limit

Description

We have added support for "limit" bids.

Acceptance criteria

GIVEN a Dal run with daily short call
WHEN -a bidder has included an "award daily short call bid" with a limit
THEN - the scheduler will only award as many matching as possible up to the limit

S-93105 - DAL Short Call - Scheduler Support Start Date/Time

Description

We have added scheduler support for the two properties if/if not start date/time.

If start date sub options:
Dates should be available as a Dates List, Dates Range, or Days of Week List.
If Time sub options:
Time should be available as Exact, Before, After, or Range.

This includes the ability to combine these two properties and the other properties (FRMS, Identifier).

Acceptance criteria

GIVEN - a DAL daily short call run

WHEN - a bidder has an "award daily short call IF/IF NOT start date" property
THEN - the scheduler will match the correct items and try to award them to the bidder (one test case for every sub option)

GIVEN - a DAL daily short call run

WHEN - a bidder has an "award daily short call IF/IF NOT start time" property
THEN - the scheduler will match the correct items and try to award them to the bidder (one test case for every sub option)

GIVEN - a DAL daily short call run

WHEN - a bidder has an "award daily short call IF/IF NOT start date IF/IF NOT start time" property
THEN - the scheduler will match the correct items and try to award them to the bidder (various test cases for various options)

S-96237 - ENY - Remove Pilot Config from ENY

Description

We have removed the following from the old pilot configuration:

Remove existing ENY Pilot rule set
Remove existing ENY Pilot config set (bid set)
Remove existing ENY Pilot absence codes
Remove existing ENY Pilot info items
Delete any pilot crew classifications from the current system
Delete any categories that are linked to any pilot crew classifications
Change base line config files
Upgrade script
Update config spreadsheet

Acceptance criteria

GIVEN - ENY system

WHEN - viewing the rules

THEN - I will no longer see rules applying to pilots

GIVEN - ENY System

WHEN - viewing the absence codes

THEN - I will no longer see absence codes relevant to pilots

GIVEN - a ENY System

WHEN - viewing the config

THEN - I will no longer see any pilot crew classifications

S-95857 - JBU - Crew Import SQ Qual

Description
We have updated the TOPS Crew import process to automatically classify crew members from Boston (BOS) and New York (JFK) into different categories based on language qualifications. This new process will work similarly to the existing CrewTrack import but will use a different method to identify language qualifications.

How It Works

The system will now use the <SpecialQuals> element with a value of SQ in the TOPS Crew file to identify a crew member's language qualifications.

If a crew member has an <SpecialQuals> element with the value SQ: They are assigned to a new, language-qualified category. For example, a crew member in the BOS-320-CA category is re-assigned to the BSQ-320-CA category.
If the crew member does not have this element: Their category will remain unchanged. For example, a crew member in BOS-320-CA without the <SpecialQuals> element will remain in the BOS-320-CA category.

This change ensures that language-qualified crew members from Boston and New York are correctly categorized upon import.

Scenario:

1. Log into the Admi UI

2. Go to the Period tab

3. Select a Period and click the "Data" button

4. Go to the import section and select TOPS Crew on the dropdown

5. Select a file where the <SpecialQuals> element with the value SQ is defined for BOS or JFK base

6. Import a file

7. Check if the crew member with the SpecialQuals = SQ is assigned to the proper category BSQ or JSQ.

Additionally, we have to keep the current behaviour for TOPS Award Export.

So in this report, crewmembers assigned to categories BSQ and JSQ must be exported to BOS and JFK respectively.

Acceptance criteria

GIVEN - as an Admin/ Scheduler

WHEN - import TOPS Crew file with <SpecialQuals>SQ </SpecialQuals> for BOS and JFK bases

THEN - crew members with SQ Special Quals are assigned to the BSQ or JSQ categories

GIVEN - as an Admin/ Scheduler

WHEN - export TOPS Awards

THEN - crew members from the BSQ or JSQ categories are exported with BOS and JFK airport codes, respectively.

S-93940 - SCX - Absence Upload Default when Activity Does not have a Time

Description

We have updated how activities without a specific start or end time are handled in the system. To prevent overlap and allow for more accurate bidding, a new default start time is applied to these activities based on a new configuration flag.

If the applymidnightoffset flag is set to True, activities without a start time will now default to starting at 02:01 (2:01 a.m.).

If the applymidnightoffset flag is set to False, activities will continue to default to starting at 00:01 (12:01 a.m.).

This change allows you to bid on trips that may have previously appeared to conflict with these activities, as a trip ending before 02:01 will now be correctly recognized as concluding on the previous day.

For example:

This is the input file from AIMS to NavBlue. It does not contain a start and end time. therefore, the system assumes 00:01 to 23:59.

Acceptance Criteria

GIVEN - the PBS system with the new configuration flag applymidnightoffset

WHEN - an activity is imported without a start time and the applymidnightoffset flag is set to True

THEN - the activity's start time defaults to 02:01 (2:01 a.m.)

GIVEN - the PBS system with the configuration flag applymidnightoffset

WHEN - an activity is imported without a start time and the applymidnightoffset flag is set to False

THEN - the activity's start time defaults to 00:01 (12:01 a.m.)

S-97003 - VXP Rule Changes

Description

For VXP, we are adding a new rule and adjusting another to manage pilot and cabin rest rules. These changes are applied through an upgrade script and documented in the config spreadsheet.

Domicile Rest

We are adding a new Pairing-DomicileRestWithTable rule for both Pilots and Cabin. This new rule will use a table to determine rest proration over a thirty or thirty one-day period.

The rule's default settings are:

ProrationTables: The rule will use the specified "Default" proration tables.
Reduced Block People: Crew members with reduced block is not excluded.
Days Off: Required days off is not reduced.
Layover Days: Layover days is not included in calculations based on either local or base time.

Reserve Rules

For Pilots, we are replacing the Reserve-TotalDaysOnUsingCreditProration rule with the Reserve-TotalDaysOff rule. The parameters for this new rule are the same as those currently configured for VXP Cabin.

Acceptance Criteria

GIVEN - A VXP Admin

WHEN - Viewing the Rule Editpr

THEN - I will see the Pairing-DomicileRestWithTable rule, in both rule sets (for Pilot and Cabin), with the following configuration:

- ProrationTableName = "Default"

- ExcludeReducedBlockPeople = 0 (i.e. false)

- ReduceRequiredDaysOff = 0 (i.e. false)

- IncludeLayoverDaysLocalTime = 0 (i.e. false)

- IncludeLayoverDaysBaseTime = 0 (i.e. false)

AND

WHEN -Viewing the Rule Editor for the Pilot rule set

THEN I will not see the Reserve-TotalDaysOnUsingCreditProration rule

AND

THEN I will see the Reserve-TotalDaysOff rule, with the following parameters:

<ProrationTableName_RES>Default</ProrationTableName_RES>

</ProrationTables>

</Proration>

</Params>

S-100716 - SCX - Job 146 to Base Time on Departure, not Check-In

Description

For SCX's go-live, we are making two key changes to the Job 146 export to ensure it aligns with AIMS's requirements.

Trip Start Date

The export will now use the departure date of the first leg as the trip's start date, rather than the check-in date. This means if a crew member checks in at 11:40 p.m. on the 29th but the first flight departs at 12:40 a.m. on the 30th, the trip is recorded as starting on the 30th.

Off Days in Export

The system will now account for midnight offsets when determining off days. If a trip operates into a new day (past midnight), that day will not be reported as an OFF day in the Job 146 export. The system will use 02:01 as the cut-off time to determine if a day should be counted as a working day. This prevents a day from being incorrectly counted as an off day if a trip ends shortly after midnight.

Acceptance criteria

GIVEN an SCX admin
WHEN - the JOB 146 is exported
THEN - the date value shown is the date on which the pairing's first leg departure date falls.

GIVEN - an SCX admin
WHEN - viewing the JOB 146 report and a trip operates into a day, taking midnight offset into account
THEN - that day is not reported as an OFF day in the JOB 146 report.

S-99403 - Externalize and Securize PBS Class API Credentials

Description

Currently, all customers using the CLASS API share the same hardcoded credentials, which poses a significant security risk. We will replace this approach with a secure secret storage solution.

This change allows each Class API server to have its own unique credentials, making the system safer and more secure for all customers.

Acceptance criteria

GIVEN - a PBS Class API installation

WHEN - two new configuration parameters are added: CLASS_API_USERNAME and CLASS_API_PASSWORD on NAVNWSParams.xml file

THEN Class API will read the configured credentials and authenticate its requests against them.

GIVEN - a PBS Class API installation

WHEN - adding a configuration parameter CLASS_API_PASSWORD on NAVNWSParams.xml file

THEN - that parameter is hashed using SHA-256 and Base64 encoded to securely store it on the configuration file using OpenSSL.

GIVEN - a PBS Class API installation

WHEN - No configuration parameters are added on NAVNWSParams.xml file ( CLASS_API_USERNAME and CLASS_API_PASSWORD)

THEN - Class API requests will return a HTTP 401 error.

25.5 Enhancements.pdf
(2.73 MB)

Related Articles