N-PBS 25.1 New Features

S-84446 - Community - Limit (in Award Pairings): Change the Default Value from "0" to "1"

 We have added the ability to request a change to the default value in the "Limit" bid line option, updating it from "0" (zero) to "1" (one). 

The current status of this bid line option: 

S-85715 - Community - Add Midnight Offset to Global Rules - Stage 1 Add New Options Inactive

We have configured Stage 1 (out of three stages) to replace existing rule-specific MidnightOffset parameters with a global rule option. Note: This is not a complete system global MidnightOffset to all rules.

1. Stage1 the system introduces the global rule option with parameters (one for each existing rule-specific MidnightOffset parameter). By the end of this stage, the new global rule option is available, and can be edited, but inactive (i.e., the values from the global option are not yet applied to the rules).
   
    
2. Stage 2 changes the system to use the numbers from the global option, while keeping the old rule-specific parameters present but inactive. Stage 2A applies this change to three biddable rules: Pairing-NoSameDayTrips, Pairing-MinDaysOff, and Pairing-MaxDaysOn. Stage 2B applies the same change to three non-biddable rules.
   
    
3. Stage 3 removes the old rule-specific MidnightOffset parameters.0.

The following new global rule option is added for all customers: 

• Option name: MidnightOffsetOptions
• Parameters:
• MidnightOffsetMinutes
• ApplyToRule_Pairing_MaxDutyDaysPerBidPeriod
• ApplyToRule_Pairing_AOffAfterB
• ApplyToRule_Pairing_MinDaysOff
• ApplyToRule_Pairing_MaxDaysOn
• ApplyToRule_Pairing_DomicileRestWithTable
• ApplyToRule_Pairing_NoSameDayTrips.
    

Note: This is added to PbsSettings.XML (similar to CaribbeanOptions (present for RGA only) and Far117Options (present for various customers)). 

Also, MidnightOffsetOptions have the type Unsigned.
 

The six other parameters, ApplyToRule_etc, have the type Boolean.
  

Values
DAL
MidnightOffsetMinutes=180
ApplyToRule_Pairing_MaxDutyDaysPerBidPeriod=1
ApplyToRule_Pairing_AOffAfterB=0
ApplyToRule_Pairing_MinDaysOff=0
ApplyToRule_Pairing_MaxDaysOn=0
ApplyToRule_Pairing_DomicileRestWithTable=0
ApplyToRule_Pairing_NoSameDayTrips=0

JBU
MidnightOffsetMinutes=120
ApplyToRule_Pairing_MaxDutyDaysPerBidPeriod=0
ApplyToRule_Pairing_AOffAfterB=1
ApplyToRule_Pairing_MinDaysOff=0
ApplyToRule_Pairing_MaxDaysOn=0
ApplyToRule_Pairing_DomicileRestWithTable=0
ApplyToRule_Pairing_NoSameDayTrips=1

HAL
MidnightOffsetMinutes=120
ApplyToRule_Pairing_MaxDutyDaysPerBidPeriod=0
ApplyToRule_Pairing_AOffAfterB=0
ApplyToRule_Pairing_MinDaysOff=0
ApplyToRule_Pairing_MaxDaysOn=0
ApplyToRule_Pairing_DomicileRestWithTable=0
ApplyToRule_Pairing_NoSameDayTrips=1
 

ASAP
MidnightOffsetMinutes=119
ApplyToRule_Pairing_MaxDutyDaysPerBidPeriod=0
ApplyToRule_Pairing_AOffAfterB=0
ApplyToRule_Pairing_MinDaysOff=1
ApplyToRule_Pairing_MaxDaysOn=1
ApplyToRule_Pairing_DomicileRestWithTable=1
 ApplyToRule_Pairing_NoSameDayTrips=1

All other ALC
MidnightOffsetMinutes=0
ApplyToRule_Pairing_MaxDutyDaysPerBidPeriod=0
ApplyToRule_Pairing_AOffAfterB=0
ApplyToRule_Pairing_MinDaysOff=0
ApplyToRule_Pairing_MaxDaysOn=0
ApplyToRule_Pairing_DomicileRestWithTable=0
ApplyToRule_Pairing_NoSameDayTrips=0
 

Acceptance Criteria:

GIVEN - an Administrator
WHEN - viewing the Rule Editor and selecting the "Global Rules"
THEN - the new option "MidnightOffsetOptions" appears in the "Rule Name" column, with the associated parameters (as described), and the initial values set as specified in the description.

AND

WHEN - selecting the new option and clicking "Edit"
THEN - I can edit the values, using a spinner for MidnightOffsetMinutes, and a checkbox for all boolean values "ApplyToRule_[XYZ]". Therefore, if I change a value, log out, and log back in, the system correctly retains the updated value.
  

GIVEN - an administrator has changed the value for any MidnightOffsetOptions parameter from its original value, and saved the change
WHEN - the database is upgraded by running the PbsDbUtil.pl upgrade process
THEN - the system retains the changed value, meaning the upgrade process does NOT overwrite it with the original value stored in the customer configuration file.

GIVEN - an administrator
WHEN - perfoming a Pairings, or Concurrent Pairing/Reserve run
THEN - the MidnightOffsetOptions are set in CoreGlobalData, and are visible in the scheduler log file.

S-86427 - Community - Add Midnight Offset to Global Rules - Stage 2A Activate New Options (Three Biddable Rules)

We have configured Stage 2A (out of three stages) to replace existing rule-specific MidnightOffset parameters with a global rule option. In this stage, the system now uses the numbers from the global option for three biddable rules: Pairing-NoSameDayTrips, Pairing-MinDaysOff, and Pairing-MaxDaysOn. The old rule-specific parameters remain present but inactive. Note: This is not a complete system global MidnightOffset to all rules.

 

1. Stage 1 introduces the global rule option with parameters (one for each existing rule-specific MidnightOffset parameter). By the end of Stage 1, the new global rule option is available and editable, but inactive (i.e., the values from the global option will not yet be applied to the rules).
   
    
2. Stage 2 changes the system to use the numbers from the global option, while keeping the old rule-specific parameters present, but inactive.
   Stage 2A applies this change to three biddable rules, while Stage 2B applies it to three non-biddable rules.
   
    
3. Stage 3 removes the old rule-specific MidnightOffset parameters.
    0.

For Pairing-NoSameDayTrips:

• The constructor for the NoSameDayTrips.cpp rule changes to expect only one parameter instead of two.
• In NoSameDayTrips.h/.cpp, mOffset is renamed to mMidnightOffset. This is set in the constructor to the MidnightOffsetMinutes value from MidnightOffsetOptions (stored in CoreGlobalData) IF, and ONLY IF ApplyToRule_Pairing_NoSameDayTrips is TRUE.
• TripRulesManager::ConvertPbsOptionToRule no longer looks for a "MidnightOffset" parameter for this rule, and only passes the one parameter "IncludeCDOs" to the rule.
• TripCoreHlbVisitor::VisitNoSameDayPairingsBid no longer references the old mBidOptions "NoSameDayTrips-Midnight", and only passes the one parameter "IncludeCDOs" to the rule.
  
   

For Pairing-MinDaysOff:

• MinDaysOffRule.cpp rule changes to expect one fewer parameter.
• The rule member mMidnightOffset remains, but is set within the constructor to the MidnightOffsetMinutes value from MidnightOffsetOptions (stored in CoreGlobalData) IF, and ONLY IF ApplyToRule_Pairing_MinDaysOff is TRUE.
• TripRulesManager::ConvertPbsOptionToRule no longer looks for the "MidnightOffset" parameter for this rule.
• TripCoreHlbVisitor::VisitMinimumDaysOffBid no longer looks for a "MidnightOffset" parameter, and passes one fewer parameter to the rule.
• TripCoreHlbVisitor::VisitPatternBid no longer looks for a "MidnightOffset" parameter for the MinDaysOff rule, and passes one fewer parameter to the rule.

For Pairing-MaxDaysOn:

• The MaxDaysOnRule.cpp rule changes to expect one fewer parameter.
• The rule member mMidnightOffset remains, but is set within the constructor to the MidnightOffsetMinutes value from MidnightOffsetOptions (stored in CoreGlobalData) IF, and ONLY IF ApplyToRule_Pairing_MaxDaysOn is TRUE.
• TripRulesManager::ConvertPbsOptionToRule no longer looks for the "MidnightOffset" parameter for this rule.
• TripCoreHlbVisitor::VisitMaximumDaysOnBid no longer looks for a "MidnightOffset" parameter, and passes one fewer parameter to the rule.
• TripCoreHlbVisitor::VisitPatternBid no longer looks for a "MidnightOffset" parameter for the MaxDaysOn rule, and passes one fewer parameter to the rule in RulesManager.h/.cpp. 

Note: The method GetOptRuleParamForCopyingIntoRuleBid, and the member mRuleParamsForCopyingIntoRuleBids is unused (after completing the above process), so they can be removed.

For rule unit tests:
 All three affected rules already have unit tests.
 For these rules, the unit tests should be updated as follows:

• The construction of the rule no longer includes a MidnightOffset parameter.
• If the rule unit test previously tested MidnightOffset, those tests remain. If not, new tests involving MidnightOffset should be added.
• The unit tests can set the global options related to MidnightOffset in a manner similar to how Far117 rule unit tests set the global options for Far117Options (by calling CoreGlobalData::SetFar117Param). Likewise, unit tests for rules affected by MidnightOffset can set the relevant CoreGlobalData values for MidnightOffsetOptions.
  
   

Acceptance Criteria:

Pairing-NoSameDayTrips rule:

GIVEN - a run for a customer with the Pairing-NoSameDayTrips rule"s MidnightOffset parameter set to a non-zero value (e.g., ASAP, HAL, or JBU), where at least one aspect of the result (e.g., an honored bid) depends on the correct application of the MidnightOffset.
WHEN - the run is completed after this change
THEN - the run results reflect the correct application of the MidnightOffset. (Note: This requires creating a scenario where an aspect of the result, such as an honored bid, depends on the proper application of the MidnightOffset. On a developer machine, it should be possible to run tests before, and after the change, comparing the scheduler log files to verify identical behavior. On test systems, only the run after the change can be tested to ensure the MidnightOffset is properly applied in the one area where the result depends on it.).

GIVEN - a run for a customer who does not have the Pairing-NoSameDayTrips rule configured as a default, but has the Pairing bid group Set Condition No Same Day Pairings bid available, along with a non-zero value for their global rule MidnightOffsetMinutes (requiring temporary changes to the global rule MidnightOffsetMinutes, and ApplyToRule_Pairing_NoSameDayTrips for a customer with that bid, such as AAY, ACA, CJT, FLE, NKS, RGA, or SCX), and at least one aspect of the result (e.g., an honored combination of trips in conjunction with the Set Condition No Same Day Pairings bid) depends on the correct application of the MidnightOffset.
WHEN - the run is completed after this change
THEN - the run result reflects the correct application of the MidnightOffset. (Note: This requires creating a scenario where an aspect of the result, such as an Honored bid, depends on the proper application of the MidnightOffset. On a developer machine, it is possible to run tests before, and after the change, and verify that the behavior changes (since before the change, the MidnightOffset is not applied to the Set Condition bid) by comparing the scheduler log files. On test systems, it is only possible to confirm that the run after the change correctly applies the MidnightOffset in the one place where the result depends on it.).
 

Pairing-MinDaysOff rule:

GIVEN - a run for a customer with the Pairing-MinDaysOff rule"s MidnightOffset parameter set to a non-zero value (e.g., ASAP), where at least one aspect of the result (e.g., an honored bid) depends on the correct application of the MidnightOffset
WHEN - the run is performed after this change
THEN - the run result reflects the correct application of the MidnightOffset. (Note: This requires creating a scenario where an aspect of the result, such as an honored bid, depends on the proper application of the MidnightOffset. On a developer machine, it is possible to run tests before, and after the change, and verify identical behavior by comparing the scheduler log files. On test systems, it is only possible to confirm that the run after the change correctly applies the MidnightOffset in the one area where the result depends on it.).

GIVEN - a run for a customer who does not have the Pairing-MinDaysOff rule configured as a default, but has the Pairing bid group Set Condition Minimum Days Off bid available, along with a non-zero value for their global rule MidnightOffsetMinutes (e.g., JBU), where at least one aspect of the result (e.g., an honored combination of trips with the Set Condition Minimum Days Off bid) depends on the correct application of the MidnightOffset
WHEN - the run is performed after this change
THEN - the run result reflects the correct application of the MidnightOffset. (Note: This requires creating a scenario where an aspect of the result, such as an honored bid, depends on the proper application of the MidnightOffset. On a developer machine, it is possible to run tests before, and after the change, and verify that the behavior changes (since before the change, the MidnightOffset is not applied to the Set Condition bid) by comparing the scheduler log files. On test systems, it is only possible to confirm that the run after the change properly applies the MidnightOffset in the one area where the result depends on it.).

GIVEN - a run for a customer who does not have the Pairing-MinDaysOff rule configured as a default, but has the Pairing bid group Set Condition Pattern bid available, with a non-zero value for their global rule MidnightOffsetMinutes (e.g., JBU), where at least one aspect of the result (e.g., an honored combination of trips with the Set Condition Pattern bid) depends on the correct application of the MidnightOffset to the Min Days Off portion of the pattern bid
WHEN - the run is performed after this change
THEN - the run result reflects the correct application of the MidnightOffset to the Min Days Off portion of the pattern bid. (Note: This requires creating a scenario where an aspect of the result, such as an honored bid, depends on the proper application of the MidnightOffset. On a developer machine, it is possible to run tests before, and after the change, and verify that the behavior changes (since before the change, the MidnightOffset is not applied to the Set Condition bid) by comparing the scheduler log files. On test systems, it is only possible to confirm that the run after the change properly applies the MidnightOffset in the one area where the result depends on it.).

Pairing-MaxDaysOn rule:

GIVEN - a run for a customer with the Pairing-MaxDaysOn rule"s MidnightOffset parameter set to a non-zero value (e.g., ASAP), where at least one aspect of the result (e.g., an honored bid) depends on the correct application of the MidnightOffset
WHEN - the run is performed after this change
THEN - the run result reflects the correct application of the MidnightOffset. (Note: This requires creating a scenario where an aspect of the result, such as an honored bid, depends on the proper application of the MidnightOffset. On a developer machine, it is possible to run tests before, and after the change, and verify identical behavior by comparing the scheduler log files. On test systems, it is only possible to confirm that the run after the change correctly applies the MidnightOffset in the one area where the result depends on it.)

GIVEN - a run for a customer who does not have the Pairing-MaxDaysOn rule configured as a default, but has the Pairing bid group Set Condition Maximum Days On bid available, with a non-zero value for their global rule MidnightOffsetMinutes (e.g., JBU), where at least one aspect of the result (e.g., an honored combination of trips with the Set Condition Maximum Days On bid) depends on the correct application of the MidnightOffset
WHEN - the run is performed after this change
THEN - the run result reflects the correct application of the MidnightOffset. (Note: This requires creating a scenario where an aspect of the result, such as an honored bid, depends on the proper application of the MidnightOffset. On a developer machine, it is possible to run tests before, and after the change, and verify that the behavior changes (since before the change, the MidnightOffset was not applied to the Set Condition bid) by comparing the scheduler log files. On test systems, it is only possible to confirm that the run after the change correctly applies the MidnightOffset in the one area where the result depends on it.)

GIVEN - a run for a customer who does not have the Pairing-MaxDaysOn rule configured as a default, but has the Pairing bid group Set Condition Pattern bid available, with a non-zero value for their global rule MidnightOffsetMinutes (e.g., JBU), where at least one aspect of the result (e.g., an honored combination of trips with the Set Condition Pattern bid) depends on the correct application of the MidnightOffset to the Max Days On portion of the pattern bid
WHEN - the run is performed after this change
THEN - the run result reflects the correct application of the MidnightOffset to the Max Days On portion of the pattern bid. (Note: This requires creating a scenario where an aspect of the result, such as an honored bid, depends on the proper application of the MidnightOffset. On a developer machine, it is possible to run tests before, and after the change, and verify that the behavior changes (since before the change, the MidnightOffset was not applied to the Set Condition Pattern bid) by comparing the scheduler log files. On test systems, it is only possible to confirm that the run after the change correctly applies the MidnightOffset in the one area where the result depends on it.)
 

S-86428 - Community - Add Midnight Offset to Global Rules - Stage 3 Remove Old Rule Parameters

We have configured Stage 3 (out of three stages) towards replacing existing rule-specific MidnightOffset parameters with a global rule option. Note: This is not a complete system global MidnightOffset to all rules.
 

1. Stage 1 will add the global rule option, with parameters (one for each existing rule-specific MidnightOffset parameter). By the end of Stage 1, the new global rule option will be present, and editable, but not active (i.e., the values from the global option will not be applied to the rules).
2. Stage 2 will change the system to use the values from the global option, while keeping the old rule-specific parameters present, but inactive.
3. Stage 3 will remove the old rule-specific MidnightOffset parameters.0.

By Stage 3, the changes from Stage 2 will deactivate all of the old options, therefore, this task focuses on removing them from both customer systems, and NAVBLUE"s configuration/code.

In the [ALC]/PbsSettings.XML files:
The NoSameDayTrips-Midnight option, found in the PbsSettings.XML files for legacy QA customers (CUR, NAV, SEC, and TCUR) is removed.

In common/RuleConfig.xsd:
The MidnightOffset parameters (associated with six rules in the main section and three rules in the Overrides section) is removed.

In the [ALC]/RuleConfig.XML files:
All MidnightOffset parameters is removed from the following rules:
 

• Upgrade Script: An upgrade script is created to remove the MidnightOffset parameter from the relevant rules for all ALCs.
  Note: For reference, see UpgradeFalconDb-1.597.pl, which is an older script that removed the MinHours parameter from multiple rules. This is a similar approach here, though it is simpler, as only old parameters are being removed without adding new ones.
  
   
• Update Configuration Spreadsheet: The configuration spreadsheet is updated to reflect the removal of the obsolete items introduced by this new feature.
  
   

Acceptance Criteria:

GIVEN - a customer with the Pairing-NoSameDayTrips rule (e.g. JBU)
WHEN - viewing the Rule Editor after upgrade
THEN - the rule no longer shows a MidnightOffset parameter

GIVEN - a customer with the Pairing-DomicileRestwithTable rule (e.g. ASAP)
WHEN - viewing the Rule Editor after upgrade
THEN - the rule no longer shows a MidnightOffset parameter

GIVEN - a customer with the Pairing-MaxDaysOnrule (e.g. ASAP)
WHEN - viewing the Rule Editor after upgrade
THEN - the rule no longer shows a MidnightOffset parameter

GIVEN - a customer with the Pairing-MinDaysOffrule (e.g. ASAP)
WHEN - viewing the Rule Editor after upgrade
THEN - the rule no longer show a MidnightOffset parameter

GIVEN - a customer with the Pairing-AOffAfterB rule (e.g. JBU Pilots)
WHEN - viewing the Rule Editor after upgrade
THEN - The rule no longer shows a MidnightOffset parameter

GIVEN - a customer with the Pairing-MaxDutyDaysPerBidPeriod rule (e.g. DAL)
WHEN - viewing the Rule Editor after upgrade
THEN - the rule no longer shows a EndMidnightOffsetMinutes parameter
 

S-86669 - Community - Add Midnight Offset to Global Rules - Stage 2B Activate New Options (3 Non-Biddable Rules)

We have configured Stage 2B (out of three stages) to replacing existing rule-specific MidnightOffset parameters with a global rule option.In this stage, the system now uses the numbers from the global option for three non-biddable rules: Pairing-MaxDutyDaysPerBidPeriod, Pairing-AOffAfterB, Pairing-DomicileRestWithTable. The old rule-specific parameters remain present, but inactive. Note: This is not a complete system global MidnightOffset to all rules.
  

1. Stage1 the system introduces the global rule option with parameters (one for each existing rule-specific MidnightOffset parameter). By the end of this stage, the new global rule option is available, and can be edited, but inactive (i.e., the values from the global option are not yet applied to the rules).
   
    
2. Stage 2 changes the system to use the numbers from the global option, while keeping the old rule-specific parameters present, but inactive. Stage 2A applies this change to three biddable rules: Pairing-NoSameDayTrips, Pairing-MinDaysOff, and Pairing-MaxDaysOn. Stage 2B applies the same change to three non-biddable rules: Pairing-MaxDutyDaysPerBidPeriod, Pairing-AOffAfterB, Pairing-DomicileRestWithTable
3. Stage 3 removes the old rule-specific MidnightOffset parameters.0.

 
For Pairing-MaxDutyDaysPerBidPeriod:

• The rule (MaxDutyDaysPerBidPeriod.cpp) is updated to expect only two parameters, instead of three.
• The member mEndMidnight in the rule (MaxDutyDaysPerBidPeriod.h/.cpp) remains, but it is set within the constructor to NavTime(0) by default. It will then add the MidnightOffsetOptions MidnightOffsetMinutes value (held on CoreGlobalData), but only if the ApplyToRule_Pairing_MaxDutyDaysPerBidPeriod value is TRUE. The comments in the MaxDutyDaysPerBidPeriod file related to Midnight should be updated, as they currently refer to old functionality.
• TripRulesManager::ConvertPbsOptionToRule no longer looks for any "EndMidnightOffsetMinutes" parameter, and only passes two parameters to the rule.

For Pairing-AOffAfterB:

• The rule (AOffAfterBRule.cpp) expects only four parameters, instead of five.
• The member MidnightOffset remains in AOffAfterBRule.h/.cpp but is set within the constructor to the MidnightOffsetOptions MidnightOffsetMinutes value (held on CoreGlobalData), only if the ApplyToRule_Pairing_AOffAfterB value is TRUE.
• In the ModifyParameterIfAllowed method, the five lines for "else if (Name == "MidnightOffset")" are removed, as MidnightOffset is no longer a valid parameter for modification through a bid.
• TripRulesManager::ConvertPbsOptionToRule no longer searches for any "MidnightOffset" parameter for this rule.
  
   

For Pairing-DomicileRestWithTable:

• The rule (DomicileRestWithTableRule.cpp) expects one fewer parameter.
• The member mMidnightOffset remains, but it is set within the constructor to the MidnightOffsetOptions MidnightOffsetMinutes value (held on CoreGlobalData), only if the ApplyToRule_Pairing_DomicileRestWithTable value is TRUE.
• In the ModifyParameterIfAllowed method, the five lines for "else if (Name == "MidnightOffset")" are removed, as MidnightOffset is no longer a valid parameter for modification through a bid.
• TripRulesManager::ConvertPbsOptionToRule no longer searchses for any "MidnightOffset" parameter for this rule.
  
   

Acceptance Criteria:
Pairing-MaxDutyDaysPerBidPeriod rule:

GIVEN - a run for a customer with the Pairing-MaxDutyDaysPerBidPeriod rule, where the EndMidnightOffsetMinutes parameter is set to a non-zero value (e.g., DAL), known to include at least one aspect of the result (e.g., an honored bid) requiring the proper application of the MidnightOffset
WHEN - the run is performed after this change
THEN - the run result reflects the correct application of the MidnightOffset. 

Note: This requires constructing a scenario where an aspect of the result (e.g., an honored bid) depends on the proper application of the MidnightOffset. On a developer machine, the run should be performed both before, and after the change, with identical behavior verified by comparing the scheduler log files. On test systems, only the post-change run can confirm the correct application of the MidnightOffset (the one area where it impacts the result).
  

Pairing-AOffAfterB rule:

GIVEN - a run for a customer with the Pairing-AOffAfterB rule, where the MidnightOffset parameter is set to a non-zero value (e.g., JBU Pilots), known to include at least one aspect of the result (e.g., an honored bid) requiring the proper application of the MidnightOffset

WHEN - the run is performed after this change

THEN - the run result reflects the correct application of the MidnightOffset.
Note: This requires constructing a scenario where an aspect of the result (e.g., an honored bid) depends on the proper application of the MidnightOffset. On a developer machine, the run should be perfomed both before, and after the change, with identical behavior verified by comparing the scheduler log files. On test systems, only the post-change run can confirm the correct application of the MidnightOffset (the one area where it impacts the result).

Pairing-DomicileRestWithTable rule:

GIVEN - a run for a customer with the Pairing-DomicileRestWithTable rule, where the MidnightOffset parameter is set to a non-zero value (e.g., ASAP), known to include at least one aspect of the result (e.g., an honored bid) requiring the proper application of the MidnightOffset
WHEN - the run is executed after this change
THEN - the run result reflects the correct application of the MidnightOffset.
Note: This requires constructing a scenario where an aspect of the result (e.g., an honored bid) depends on the proper application of the MidnightOffset. On a developer machine, the run should be executed both before, and after the change, with identical behavior verified by comparing the scheduler log files. On test systems, only the post-change run can confirm the correct application of the MidnightOffset (the one area where it impacts the result).
 

S-89521 - Community - Award Reserve Day

We added a new rule "Award Reserve Day" bid which applies to all PBS customers with the Reserve Module, expanding functionality beyond AAY & AAYP.
  

Note: To add this bid to the configuration for all other customers use categoryoptions.XML.

Acceptance Criteria:

GIVEN - a bidder
WHEN - editing Reserve bid groups
THEN - I can add, or edit an Award Reserve Day bid, using either a single date, or a list of dates.

GIVEN - an admin
WHEN - performing a concurrent run where some bidders have used the Award Reserve Day bid
THEN - the run processes the bid properly (Eg: tries to honor it, shows honored, or partially honors it on the reasons report).
 

S-83985 - POE - SDO Code for Blank Days - PBS Rule

We have added an enhancement to ensure that the export process reflects all Scheduled Days Off (SDO) accurately, providing a more seamless, and streamlined data export. For instance, as a POE admin, the goal is to implement the export of blank days as "SDO" in the N-OC export file. This is done after the pairing and RSV (Reserve) assignments are completed by PBS. Then, these blank days are exported in a similar manner to General Duty(GD) days with specific parameters, and details as outlined below.

Example: A GD on the 11th is exported as below.
<api:RosterActivity>
<api:ActivityType>REFERENCEACTIVITY</api:ActivityType>
<api:ActivityCode>GD</api:ActivityCode>
<api:StartAirportCode>YOW</api:StartAirportCode>
<api:EndAirportCode>YOW</api:EndAirportCode>
<api:Start>2024-10-11T04:01:00</api:Start>
<api:End>2024-10-12T03:59:00</api:End>
</api:RosterActivity>
 

Please export all blank days with the activity code "SDO," using a start time of 0001-2359, converted into UTC.

 Add four parameters to PBSSettings:

1. CustData-NOCExportParam-ExportBlankDays=1 OR 0 (1 for POE)
2. CustData-NOCExportParam-BlankDayCode (SDO for POE)
3. CustData-NOCExportParam-BlankDayStartTimeMinutes (1 for POE)
4. CustData-NOCExportParam-BlankDayEndTimeMinutes (1439 for POE).0.

Note: Refer to the image on the right, showing the current blank days in the schedule report (highlighted in yellow). These are not to be changed, and are for visual reference only.

File to change below:

Acceptance Criteria:

 GIVEN - a POE run
WHEN - generating the NOC export file
THEN - days within the period that do not have other activities (e.g., pairings, RSV, training, GD) have a section exported to represent SDO for that day, as described.
 

S-84447 - ACA/RGA - Pairing Number Departing On: Change the Default Value for
 "Ordered" to "YES"

We introduced a change to the default value of "NO" to "YES" for the Award Pairings If Pairing Number Departing On bid line for both ACA, and RGE (other companies are not impacted).

 These enhancements include:

• Updating default value for Award Pairings If Pairing Number Departing On to "YES" for ACA, and RGE.
• Reflecting this default in Add Bids Mode within the Pairings tab.
• Ensuring that this change applies only to ACA, and RGE, with no impact on other companies.
• Updating the configuration spreadsheet to reflect these changes.
  
   

Acceptance Criteria:

GIVEN - a RGA, and ACA Bidder
WHEN - choosing to Award Pairings If Pairing Number Departing On in Bids Tab
THEN - the default is YES.

GIVEN - a RGA, and ACA Bidder
WHEN - choosing to Award Pairings If Pairing Number Departing On in Pairing tab with add bid mode enabled
THEN - the default is YES.

GIVEN - ACA Bidder
WHEN - selecting the default value in the "Limit" bid line option from
THEN - 1 should be an option .

S-84456 - ACA/ARGA - Followed by Bid Option: Set "Allow Intervening Activities" as the
 Default Selection

For ACA, and RGA, we implemented a new functionality for "Allow Intervening Activities" in Category Options.XML by adding "1" for all instances. To use this new functionality, in the "Followed By" bid line option, the default value of "Allow Intervening Activities" is changed from "not selected" (as shown in the CURRENT STATE image below) to "selected" (as shown in the DESIRED STATE image; next slide). Note: this change requires selecting two options (one under "Award", and one under "Followed By") to enable the selection of intervening activities.

CURRENT STATE:

DESIRED STATE:   

Acceptance Criteria:

GIVEN - ACA - RGA Bidder
WHEN - selecting the Followed By bid line option
THEN - the default value is selected (by default) as shown in the above DESIRED STATE image.

S-85440 - HAL - Configure for Training Events Module

For HAL pilots (not HALC), the training module is configured based on the attached spreadsheet. Note: This requires an upgrade script to add rules.

 Updated configuration spreadsheet:

• Add training bids: Configure based on HAL training bids in the CategoryOptions sheet.
• Add training rules: Based on HAL training rules in the RulesConfig sheet, these rules are added to existing databases through an upgrade script.
• Add import formats: Include TrainingPatterns, and TrainingRequirements as per the PbsSettings sheet.
• Add export formats: Include RunManagerCompletedTrainingRunsReportsOutput, etc., based on the UserTypeOptions sheet.
• Add ApplicationModules: Add "Training" in PbsSettings, and three TrainingRequirements options (AllowEarly, etc.).

Furthermore, we updated the report templates in code/pbsreporting/reports/hal as follows:

• RunDetailSummary.txt (used for the Stats report) includes training-related sections, such as HaveJuniorAssigning, TrainingStatistics, and TrainingDetails, similar to other customers with the training module.
• Add four training-specific report templates: TrainingPatternDetails.txt, TrainingPatternsFilter_EN.txt, TrainingPatternSummary.txt, and TrainingRequirements.txt, following the format of other customers with the training module.
  
   

Acceptance Criteria:

GIVEN - a HAL admin
WHEN - viewing the import screen
THEN - the training pattern, and training requirements import options are visible.

GIVEN - a HAL admin
WHEN - viewing reports for a completed training run
THEN - the options for PBS Crew Absence & PBS Training Awards .csv spreadsheet display.

GIVEN - a HAL bidder
WHEN - logged into the bid UI
THEN - a training tab displays

AND

THEN - training bid options are added as specified in the category bid options spreadsheet.

GIVEN - a HAL admin
WHEN - viewing the rule editor
THEN - a rule set for training rules appears, containing the options specified in the rule configuration spreadsheet.
 

Acceptance Criteria Continued:

GIVEN - a HAL admin
WHEN - viewing the configuration tab
THEN - a sub tab called "TrainingGroups" displays.
  

AND

THEN - training groups can be added.

GIVEN - a HAL admin
WHEN - generating a Run Statistics report for a completed Training run
THEN - the training-related sections appear, similar to those for other customers with the training module.

GIVEN - a HAL admin
WHEN - viewing the Reports tab
THEN - a "Training Reports" sub-tab appears, and training reports like "Training Pattern Details", and "Training Requirements" are generated.
 

S-86856 - HAL - Waive Rest After CQ

For HAL, we have added two rules to the Waive Rest After CQ. This applies to the following rule sets: 

• Configure the reserve rule "Days Off Before and After CQ" as YES, Waivable:
• NumDaysOffBefore=0
• NumDaysOffAfter=1

• Configure the pairing rule "Days Off Before and After CQ" as YES, Waivable:
• NumDaysOffBefore=0
• NumDaysOffAfter=1
• DisallowSameDayBefore=0
• DisallowSameDayAfter=0

Note: Rules are configured with the "rule mode remove".

Furthermore, we have enhanced the existing waive bid "WaiveRestAfterTraining" to HAL/CategoryOptions.XML for both current, and default bids, in both Pairing bid groups (adding it to the existing waive section), and Reserve bid groups (adding a waive section since it does not exist).

 In UserTypeOptions:

Nonetheless, we have completed an upgrade script to incorporate the two rules.

Note: Update the configuration spreadsheet.   

Acceptance Criteria:

GIVEN - a HAL Admin
WHEN - editing an Absence code
THEN - the CQ checkbox displays.

GIVEN - a HAL Admin
WHEN - viewing the Rule Editor (in the two rule sets)
THEN - the two new rules as per the description displays.

GIVEN - a HAL Bidder
WHEN - viewing the Bid UI
THEN - the option WaiveRestAfterTraining in Pairing and Reserve bid groups appears.

GIVEN - a HAL admin
WHEN - completing a run, if a bidder is in a Reserve bid group with the "WaiveRestAfterTraining" rule and has a CQ Absence, then bids for something after training is only legal after the Waive Rest rule is applied.

GIVEN - a HAL admin
WHEN - completing a run, if a bidder is in a Pairing bid group with "WaiveRestAfterTraining," has a CQ absence, and bids on something after training that is only legal once the Waive Rest rule is applied
THEN - the run applies the waive properly.

S-87294 - MXY - Pairing Report for MXY to Include Both Flight Credit, and Block Hours

For MXY, we have added the feature to include both flight credit, and block hours in the Pairing report.

Acceptance Criteria:

GIVEN - a MXY ADMIN
WHEN - when viewing the Pairing Report
THEN - both flight credit, and block hours display.

GIVEN - a MXY ADMIN
WHEN - viewing the Pairing details in the Admin UI
THEN - both flight credit, and block hours display.

GIVEN - a MXY BIDDER
WHEN - viewing the Pairing details in the Pairing tab
THEN - both flight credit, and block hours display.
 

S-87297 - JZA - Vacation GDO Bidding Change

For JZA, we created a new approach to improve the bidding process for VAC GDOs. First, NAVBLUE no longer allows bids outside of the designated bid month. Additionally, NAVBLUE has implemented a system to recognize that VAC GDOs one, and two (out of three allowed) are part of the previous bid period, preventing PBS from offering them three more in the new bid month.

Example: August 2024 – VAC is from August 25th to 29th.

Other Issues to Address:

No Date selected Error

New Errors: Please select days eligible to adjacent block of vacation

New Error: No Bid Line Type Selected 

Acceptance Criteria:

GIVEN - a JZA Bidder
WHEN - bidding VAC GDOS
THEN - PBS recognizes that when bidding for September, selecting September 1st counts as the third VAC GDO from the previous month"s vacation.

GIVEN - a JZA Bidder
WHEN - bidding VAC GDOS
THEN - PBS does not allow bidding outside of the current bid period.

GIVEN - a JZA Bidder
WHEN - bidding VAC GDOS
THEN - PBS only allows me to bid for the three GDOs attached to my vacation. 

S-87594 - POE - Change Functionality of GDO Opt Out

We have created a feature that allows bidding to only WAIVE ONE of these days, rather than selecting both, or the one adjacent to the vacation. Note: Support Portal examples demonstrate the current functionality.

Example: The customer provided a breakdown of how they want the VAC GDO waiver option to function.

Acceptance Criteria:

GIVEN - a POE Bidder
WHEN - bidding to opt out of VAC GDOS
THEN - the system allows selecting GDOs. See image below.

S-87265 - ACA - Pairing-ReserveRest Rule

We have introduced an enhancement to the Pairing-ReserveRest Rule, aligning its functionality with the existing behavior of the Pairing-DomesticHomeRest, Pairing-OverseasHomeRest, and Pairing-DesignedOSHomeRest rules. This enhancement ensures that intervening activities are ignored only if they are a non-WorkForDuty absence, following the same logic used in the other rules.

Example: Three actvities (A, B, C):

• A=Pre-Awarded HistoryReserveAward pairing, followed by
• B=Intervening pre-awarded activity, followed by *Res
• C=First newly-awarded pairing in the new period.
  
   

In this case:

If "C" absence is considered a non-WorkForDuty absence, the change to the Pairing-ReserveRest rule to align with the other rules, results in the rest being enforced (i.e., ignoring the "C" absence).

If "B" is:

• a non-WorkForDuty absence, the relevant rest is enforced between A, and C (e.g. this results in the rest being enforced in both the original and most recent cases because absence code "C" is non-WorkForDuty).
• a WorkForDuty absence, the rest is not enforced between A, and C.
• another pre-awarded pairing, the rest is not enforced between A, and C.

Note: The article crwTN - PBS Rules For Trip Lines - Excluding FARs And CARs is updated with the new specification of this rule.
 

Acceptance Criteria:

GIVEN - a PBS scheduler
WHEN - performing runs, if a WorkForDuty absence is present between the Historical Reserve assigned activity, and the first newly Awarded Pairing
THEN - the rest is not enforced.

GIVEN - a PBS scheduler
WHEN - performing runs, if a Non-WorkForDuty absence is present between the Historical Reserve assigned activity, and the first newly Awarded Pairing
THEN - the rest is enforced.

S-89685 - HALC - Add Waive Calendar Day Free from Duty - Reserve

We are adding the Waive for Calendar Day Free From Duty for Reserve back to the HALC Configuration. Note: this reverses the change made in S-78749.

 Impacted: 

• Reserve
• MaxDaysOn Rule.

Upgrade Script:

• add waivability from the Reserve rule
• no need to edit existing bids at this time.
  
   

Acceptance Criteria:

GIVEN - a HALC Planner
WHEN - viewing the rule editor
THEN - the rule (Reserve MaxDaysOn) displays but with waivability (Bidkey - CalendarDayFreeFromDuty & RuleMode- Remove).

GIVEN - a HALC bidder
WHEN - editing a reserve bid group
THEN - the bid Waive Calendar Day Free From Duty displays.
 

S-89707 - POE - Make IOE Pairings Flaggable

We have added a fix for the error message "run not found" that appears when the scheduler tries to flag certain IOE pairings.

Acceptance Criteria:

GIVEN - POE admin
WHEN - flagging IOE Pairings
THEN - any pairings manually added to the activities under a LC airman are found, and flaggable as IOE pairings.
 

S-80620 - JBU - Local file - Import Withheld Pairings from JBU"s "TOPS" Provided in XML Format

We have enhanced a new integration to import Withheld Pairings data files generated by the TOPS CREW system. JBU has requested the ability to import Withheld Pairing data files from the TOPS CREW system. Every month, before bidding begins, N-PBS requires the relevant data for the requested period in which the bidding will take place. The data extract includes Withheld Pairing information. Initially, this functionality focuses on enabling the manual import of files.

 These new features include:

• A TOPS Withheld Pairings Option in the Import Dropdown.
• The Withheld Pairings Column shows the results of the import.

 Note: The admin imports the Withheld Pairings, which are not assigned to FOs within N-PBS (similar to Initial Operating Experience (IOE) pairings). Withheld Pairings are essentially IOE pairings.

Example: As a JBU admin, I want to be able to import the TOPS Withheld Pairings file, so that the data is populated into the database and updated
 

Main tasks: 

1. Create a new entry for TOPS Withheld Pairings and populate data into the database.
2. Create an entry in the dropdown for imported files named TOPS Withheld Pairing.
3. Create a TOPS Withheld Pairings column to show the import results. Note: The column displays in the "Pairing Data Status" table.
4. Create the mechanism of matching the imported Witheld Pairings to the correct date, and associate them with the CrewID assigned to the pairing during the run. As a result, only the Name and Start elements are processed, while other fields are not validated.
   
    
5. The database changes when process completed.
    0.

Scenario for JBU
 Preconditions:

1. The TOPS files (Crew, Pairings, Historical Pairings, Absences) are imported.
2. The run for CA is completed.
3. The awards are exported from N-PBS to the TOPS system.
4. The Witheld Pairings file is generated based on the exported N-PBS file.0.

After completing development JBU admin should be able to:

1. Log in to the Admin UI for JBU.
2. Go to the Periods tab.
3. Click the "Data" button for the selected period.
4. Go to the "Import Files" section, and click the dropdown menu.
5. Select the "TOPS Withheld Pairings" option.
6. Click the "Choose file" button, select the appropriate.XML file, and open it.
7. Click the "Import" button.
     0.

Expected result:

• The import logs display.
• The file is imported successfully.
• The Withheld Pairings appear in the IOE Pairings tab. Using the awards previously stored in the N-PBS system, these pairings, and runs are completed prior to the "normal" roster runs.
  
   

Error messages:
Error messages are specific to the root cause of the issue. While the square frames the failure message, it is important to include the relevant field.

 The error messages are displayed in the "Import Files" section:

For JBU, we have enhanced the Withheld Pairings extraction process from TOPS CREW SIT. In the image below, there are 10+ pairings marked as Withheld (WHD marked on a pairing), and the file has been extracted.
 

Note: The Withheld Indicator does not appear in the extracted file. 

Acceptance Criteria:

GIVEN - a JBU admin
WHEN - I click "Import", and select the "TOPS Withheld Pairings" file that does not have the file extension .XML
THEN - importing fails

AND an error message displays that the file uploaded is not of type .XML

GIVEN - a JBU admin
WHEN - I click "Import", and select the "TOPS Withheld Pairings" file, which is in the correct format with the .XML extension.
THEN - it gets imported into the system without an error

AND the "TOPS Withheld Pairings" column in the "Pairing Data Status" section updates to reflect the results of the import (it turns green)

AND Withheld Pairings display in the IOE Pairings tab under the "Flagged as IOE" field.

S-81900 - JBU - Server Upload - Upload JBU"s "TOPS CREW" via SFTP During Crew Roster Awards Export

We have added a new feature to generate the Crew roster report after publishing a run. This enhancement places the file into the JBU SFTP server under either /incoming/uat or /incoming/stg, depending on the server used to generate the data for the run. For development purposes, the /incoming/sat folder can be used for testing. Note: JBU documentation specifies that the file should be compressed, name starting with "R-", and have the ".XML.gz" extension.
  

Crew Roster Awards
 The Roster Awards file generated from the NAVBLUE system to the TOPS CREW system contains the Roster Awarding details for the entire bid period. The NAVBLUE system exports the Roster Award file once the awarding process is completed. Previously, JetBlue"s bid awarding was not done for all crew members at once. Instead, the awarding for the CA position was processed first, and included in a single file, followed by the FO awarding in a separate file, and finally, the awarding for all Inflight crew members is part of a separate file.

The roster awarding in the NAVBLUE system includes awards for both Pairings, and Reserve activities. In addition, the line type information is included in the Roster Award file. Crew members awarded with pairings are categorized as Line Holders (LH), while those awarded Reserve activities are categorized as Line Reserve  (LR).

Nonetheless, the Roster Award file generated from the NAVBLUE system is uploaded to an SFTP folder, and TOPS CREW retrieve it from the same location. The Roster file load process into the TOPS CREW system is not fully automated. Once the Roster Award file is received, it appears on the Roster Load screen within the TOPS CREW system for the user to action. Then, the user performs business validations, and conducts various legality checks before loading the award details into the system.

Acceptance Criteria:

[Server upload] Upload JBU"s "TOPS CREW" via SFTP during Crew Roster Awards export.

S-83394 - JBU - Server Upload - Import TOPS Historical Block Time File from JBU"s "TOPS CREW" via Webservice API

For JBU, we implemented an evolution to request Crew Planning data from TOPS CREW to initiate the preferential bidding process. This includes importing the file from the webserver, as opposed to loading it from a local device. Thus, ensuring more efficient and centralized data retrieval. The enhanced preferential bidding process: 

1. Pull request initiated by NAVBLUE administrator every month before the preferential bidding begins.
2. TOPS CREW exports snapshot data based on the bid period start, and end dates received in the request.
3. The request period is determined by the NAVBLUE system.
4. Data extract includes:
    a.     Master pairing information for the absence activities (all non-flying activities of the crew members).
5. TOPS CREW generates data in XML file format according to NAVBLUE specifications.
6. Data is shared with the NAVBLUE system once generated.
7. NAVBLUE invokes a web service API exposed by the TOPS CREW system to request the information.0.

Note: Please be aware that the implementation details, such as the webservice API and the data format, should align with NAVBLUE"s system (specification in XML file format), and the technical requirements from TOPS CREW.  

Currently, the Interface module allows the import of crew members" "Absences" data through a single method: file integration.

Evolution requested

The integration of crew members" "Absences" data (through a Webservice API call), and the imported data stored in the NAVBLUE database has the same result as the existing file import option.

Webservice API:

The objective is to export Crew Absence Activities from the TOPS CREW system to the NAVBLUE system. These absence activities include: 

• non-availability
• other activities such as vacations, reserve activities, training, sick leave, office duty, etc. 

This pull request, initiated by NAVBLUE is to retrieve the relevant snapshot data before the preferential bid process begins. Then, the extracted data is provided in the form of an, XML file through the SFTP channel and transferred to the NAVBLUE system.

 Data type definitions for the response information are then validated and the file is named “Crew_Absence_Activities_Export_YYYYMMDDTHHMMSS".

Acceptance Criteria:

GIVEN - a JBU admin
WHEN - I navigate to "integrated imports" (Periods Tab > Data), and click "Historical Block Time"
THEN - it gets imported into the system without an error

AND the column "TOPS Historical Block Time" in the "Pairing Data Status " section is updated to reflect the results of the import
   

GIVEN - a JBU admin
WHEN - I navigate to "integrated imports"(Periods Tab > Data), and click "Historical Block Time"
THEN - it gets imported into the system without an error

AND the data for Historical Pairings is explicitly verified on the UI

GIVEN - a JBU admin
WHEN - I navigate to "integrated imports"(Periods Tab > Data) and click "TOPS Historical Block Time" (which contains files with formatting that is not correct, and are being imported)
THEN - importing fails (Note: There are no partial imports.)

AND an error message displays indicating that the uploaded file does not have the correct formatting, specifying the invalid field entry, and the corresponding crewID.

GIVEN - a JBU admin
WHEN - I navigate to "integrated imports"(Periods Tab > Data), connect to the server (which holds files with extensions that are not correct), and click "TOPS Historical Block Times"
THEN - importing fails

AND an error message displays that the uploaded file is not of type .XML.

S-87785 - JBU - Server File Import - Import Withheld Pairings via Webservice API

We have extended the functionality established in S-80620 for importing the TOPS Withheld Pairings file. This enhancement assists the final integration with TOPS by establishing a direct connection to their server. Through this connection, the Administrator can now send a request from the N-PBS application to obtain the TOPS Withheld Pairings file. Once the data is received, the file is automatically imported into the N-PBS system. Upon a successful import, the changes follow the same process as before.
Note: The schema, and validation checks completed during the import remain the same, with no changes made. The same applies to the pairing data status table.

Example: As a JBU admin, I want to be able to import the TOPS Withheld Pairings file directly from the TOPS Crew application so that the data is populated into the database, and updated.

Main tasks:

1. Create an integration by calling a Webservice API exposed from the TOPS CREW system, and store the imported data in the N-PBS database: The period for which the data is requested for is determined by the N-PBS system (usually corresponding to the date range for a requested period).
2. Creation of the "Integrated Import" section for automatic import of the files.
3. The table with the IOS Pairings is filled in.0.

Note: TOPS CREW generates the respective data in .XML file format as per the N-PBS specification, and shares it with the N-PBS system over the SFTP channel.

Current solution: Manual import of the .XML file: S-80620.

After the enhancement the import of TOPS Absences through the Webservice API is similar to the N-OC solution:
1. The Server Address needs to be added manually in the Integration tab.
 Note: The label "N-OC Server Address" has to be changed to "TOPS CREW Server Address".

2. In the "Periods" tab for data import there is a new "Integrated Imports" section. See the image below: 

• Instead of labelling the dropdown "N-OC Server", it is now "TOPS CREW Server"
• There is a new TOPS Withheld Pairings button.

Note: Other buttons with the TOPS prefix will emerge as development continues on other imports.

Data type definitions for the response information are then validated and the file is named “Crew_Absence_Activities_Export_YYYYMMDDTHH:MM:SS”.
  

Acceptance Crietria:

GIVEN - a JBU admin
WHEN - I navigate to the "Periods" Tab to import data for a period
THEN - the new "Integrated Imports" section displays with the "TOPS Server" dropdown, and the "TOPS Withheld Pairings" button

GIVEN - a JBU admin
WHEN - I go to the "Integrated Imports" section, located in the "Periods" tab

AND I click the "Withheld Pairings" button

THEN - the TOPS Withheld Pairings file should import into the system without an error

AND the column "Withheld Pairings" located within the "Pairing Data Status" section is updated to reflect the results of the import.
 

S-89882 - ASAP - FTMS Code

We have enhanced the existing functionality for Training Pairings in the O3 file (e.g., starting with FTMS.xxx). These pairings now use the activity code embedded within the pairing as the "Absence Codes" for that day, as implemented in the 24.1 release. However, the system has a workaround, as the field schedulingCreditTime is missing from the O3 file, which prevents the direct use of the credit value of the activity. Nonetheless, due to the update, PBS no longer relies on the SchedulingCreditTime field from the O3 file for the credit value for the activity. Instead, the credit value for an activity is determined by the “Absence Codes” configured in PBS. 

Note: This simplifies the logic by aligning it with the existing “Absence Codes” configuration.

Example 1: (PCMV) FTMS.539782

• Trip Name: FTMS.539782
• ActivityType: PCMV.

The absence code embedded in the pairing determines the absence for that day.  

After the import (below image):  

• The name is PCMV (FTMS.539782) - no change
• The credit value is not populated from the file form schedulingCreditTime element
• The credit value is taken from the Absence Codes table (below image):

Example 2: FTMS.539454

• Trip Name: FTMS.539454
• ActivityType: without activityType.

After the import (image below): 

• The name is FTMS (FTMS.539454) - no change
• The credit value is taken from the "Absence Codes" table (image below)

Acceptance Criteria:

GIVEN - The O3 files
WHEN - imported with "Training Activities"
THEN - the credit value is taken from the "Absence Code" table

AND display in the Activity table dedicated to employees.

S-90304 - ASAP - Enhance Pairing-RestBeforeAndAfterAbsences Rule

We have created a solution to address the issue where a person using "Waive Base Rest" had 12 hours enforced before a non-CQ training absence. These new features include:

• Enhancing the Pairing-RestBeforeAndAfterAbsences rule to support a new parameter called "CQOnly," which will function similarly to the existing "TrainingOnly" parameter, but will refer to the CQ flag instead of the Training flag.
• Modifying ASAP to include two instances of the Pairing-RestBeforeAndAfterAbsences rule.
• Ensuring that when a person bids "Waive Base Rest" (reducing DomesticHomeRest and OverseasHomeRest from 720 to 630), the rest before non-CQ training (after a pairing) will be reduced to 630, while the rest before CQ training will remain at 720.
    

These features take effect through the following actions:

• Updating the configuration spreadsheet to reflect the changes.
• Updating the rule documentation to include the new "CQOnly" parameter.
• Adding an upgrade script to ensure the "CQOnly" parameter is set to FALSE for all other customers who have the rule. 

Acceptance Criteria:

GIVEN - an ASAP admin
WHEN - viewing the rule editor
THEN - there are two instances for the Pairing rest before, and after absences rule:

1. first instance with "TrainingOnly", enforcing 630 before, and after the absence
   
    
2. second instance with "CQOnly", enforcing 720 before, and after the absence0.

AND

WHEN - performing a scheduler run and attempting to award a pairing before a non-CQ training absence with a gap of more then 630 minutes but less then 720 minutes, and the bidder has Bid Waive base rest.
THEN - the scheduler allows that award. 

S-85334 - SCX - Add Midnight Offset to Set Condition Preferences: ConsecutiveDaysOff in a Row

For SCX, we have added a new parameter, ApplyToRule_Pairing_ConsecutiveDaysOff, to the Global Midnight Offset Options. This parameter is included for all customers in their PbsSettings.XML file, within the existing MidnightOffsetOptions section, alongside other parameters like ApplyToRule_Pairing_[...].

An upgrade script is required to add this new option to existing systems:

• The initial value for SCX is 1.
• The initial value for all other customers is 0.
• Update the Configuration Spreadsheet (PbsSettings sheet) accordingly.
• Implement the necessary C++ code to convert/set this option, similar to how other parameters like ApplyToRule_Pairing_[...] are handled.
  
   

Modify the Pairing-ConsecutiveDaysOff rule to support MidnightOffset:

• Only when MidnightOffsetMinutes is non-zero and ApplyToRule_Pairing_ConsecutiveDaysOff is TRUE. For reference, compare with other rules that already support the MidnightOffset.
• Add a unit test for the Pairing-ConsecutiveDaysOff rule (which currently does not exist), ensuring it tests the MidnightOffset functionality.
• Update the Rules Reference Manual to describe how the MidnightOffset global rule option is used with this rule.

Acceptance Criteria:

GIVEN - an Administrator
WHEN - viewing the Rule Editor, and selecting the "Global Rules"
THEN - the new parameter is visible within MidnightOffsetOptions, with its initial value set as described.

AND

WHEN - selecting the new parameter and clicking "Edit"
THEN - the value of the new parameter can be edited using a checkbox, so that any changes are correctly remembered by the system after logging out, and logging back in.
   

GIVEN - an administrator
WHEN - completing a Pairings run or Concurrent Pairing/Reserve run
THEN - the new parameter is set on CoreGlobalData, which is visible in the Scheduler Log file.

GIVEN - a customer with MidnightOffsetMinutes set to a non-zero value. ApplyToRule_Pairing_ConsecutiveDaysOff is set to TRUE. The "Set Condition Consecutive Days Off In A Row" bid is available. The customer has a run that includes at least one aspect requiring the proper application of the MidnightOffset. This includes an honored combination of trips with the Set Condition Consecutive Days Off In A Row bid, which impacts the Pairing-ConsecutiveDaysOff rule.
WHEN - the run is completed
THEN - the run results correctly reflect the application of the MidnightOffset to the Pairing-ConsecutiveDaysOff rule.
 

S-85335 - SCX - Add Midnight Offset to Set Condition: Days Off with/opposite Employee (Part One)

We added a new parameter, ApplyToRule_Pairing_DaysOffWithOrOppositeEmployee, to the Global Midnight Offset Options for all customers in their PbsSettings.XML file. This is within the existing MidnightOffsetOptions, alongside other parameters like ApplyToRule_Pairing_[...]. Note: An upgrade script is required to introduce this new option to existing systems.
  

An upgrade script is required to add this new option to existing systems:

• The initial value for SCX is one.
• The initial value for all other customers is zero.
• The Configuration Spreadsheet PbsSettings sheet is updated
• The necessary C++ code is implemented to convert and set the option, similar to other parameters.
  
   

Modify the Pairing-XDaysOffInGroupOfYDays Rule to Support MidnightOffset:

Currently, the Pairing-XDaysOffInGroupOfYDays rule is used exclusively for Days Off With/Opposite Employee bids. However, based on its design, and naming, it can potentially be used for other purposes in the future. The rule is only created from that specific bid, with its parameters calculated internally within the system.

To extend its flexibility, it accepts a MidnightOffsetMinutes parameter (e.g., the second parameter, before the dynamically calculated group of day indices). This allows the code that creates the rule to specify which MidnightOffsetMinutes value to use.

The required days off (based on the target person’s schedule) are passed into the rule as Day Indices. As a result, the methods calculating these days for input into the rule identify the applicable MidnightOffset. This is non-zero only if the global option MidnightOffsetMinutes is non-zero, and ApplyToRule_Pairing_DaysOffWithOrOppositeEmployee is TRUE. If neither condition is met, the MidnightOffset is zero.

 For instance, TripBidGroupCAManager::GetDynamicRuleParams identifies the MidnightOffsetMinutes, and passes this value to the method LineHolderCoredata::GetInPeriodDayIndices, which then accounts for the MidnightOffset when calculating day indices.

Note: As a comparison, other rules already support MidnightOffset, though this rule differs in that it takes MidnightOffsetMinutes as a parameter.

Additional Tasks:

• Add a unit test for the Pairing-XDaysOffInGroupOfYDays rule, which currently does not exist. The test should include verifying the application of the MidnightOffset.
• Update the Rules Reference Manual for this rule to describe the usage of the MidnightOffset global rule option.
  
   

Acceptance Criteria:

GIVEN - an Administrator
WHEN - viewing the Rule Editor, and selecting the "Global Rules"
THEN - the new parameter appears within MidnightOffsetOptions, with its initial value set as described

AND

WHEN - selecting the new parameter and clicking "Edit"
THEN - I can edit the value of the new parameter using a checkbox, ensuring the system correctly remembers any changes after logging out, and back in.

GIVEN - an administrator
WHEN - completing a Pairings run or Concurrent Pairing/Reserve run
THEN - the new parameter is set in CoreGlobalData and becomes visible in the scheduler log file.

GIVEN - a customer with MidnightOffsetMinutes set to a non-zero value. ApplyToRule_Pairing_DaysOffWithOrOppositeEmployee set to TRUE. The "Set Condition Days Off With or Opposite Employee" bid available. A run that includes at least one result (e.g., an honored combination of trips with a "Set Condition Days Off With or Opposite Employee" bid) requiring proper application of the MidnightOffset to identify the other person"s days off (i.e., the more senior person targeted by the bid).
WHEN - the run is completed
THEN - the run results correctly reflect the application of the MidnightOffset in identifying the other person"s days off (i.e., the days off of the more senior person targeted by the bid).

GIVEN - a customer with MidnightOffsetMinutes set to a non-zero value, ApplyToRule_Pairing_DaysOffWithOrOppositeEmployee set to TRUE, and the "Set Condition Days Off With or Opposite Employee" bid available, and a run for the customer that includes at least one result (e.g., an honored combination of trips with the "Set Condition Days Off With or Opposite Employee" bid) requiring proper application of the MidnightOffset to identify the current person"s days off (i.e., the person who made the bid).
WHEN - the run is completed
THEN - the run results reflect the proper application of the MidnightOffset in identifying the current person"s days off (i.e., the person who made the bid).
 

S-88602 - SCX - Add Midnight Offset to Set Condition: Days Off with/opposite Employee (Part Two)

We have introduced a new parameter to the Global Midnight Offset Options: ApplyToRule_Pairing_DaysOffWithOrOppositeEmployee. This is added for all customers in their PbsSettings.XML file, within the existing MidnightOffsetOptions, alongside other parameters like ApplyToRule_Pairing_[...].

 Note: An upgrade script is required to add this new option to existing systems.      

Acceptance Criteria:

GIVEN - an Administrator
WHEN - viewing the Rule Editor, and selecting the "Global Rules"
THEN - the new parameter appears within MidnightOffsetOptions, with its initial value as specified in the description.

AND

WHEN - selecting the new parameter and clicking "Edit"
THEN - the value of the new parameter can be edited using a checkbox, ensuring the system correctly remembers the updated value after logging out, and logging back in.

GIVEN - an Administrator
WHEN - complete a Pairings run or Concurrent Pairing/Reserve run
THEN - the new parameter is set in CoreGlobalData and becomes visible in the scheduler log file.

GIVEN - a customer with MidnightOffsetMinutes set to a non-zero value. ApplyToRule_Pairing_DaysOffWithOrOppositeEmployee is set to TRUE.The "Set Condition Days Off With or Opposite Employee" bid available. A run for that customer includes at least one result (e.g., an honored combination of trips with the "Set Condition Days Off With or Opposite Employee" bid), which requires the proper application of the MidnightOffset to identify the other person’s days off (i.e., the days off of the more senior person targeted by the bid).
WHEN - the run is completed
THEN - the run result reflects the proper application of the MidnightOffset in identifying the other person"s days off (i.e., the days off of the more senior person targeted by the bid).

GIVEN - a customer with MidnightOffsetMinutes set to a non-zero value and ApplyToRule_Pairing_DaysOffWithOrOppositeEmployee set to TRUE. The customer has the "Set Condition Days Off With or Opposite Employee" bid available. A run for that customer includes at least one result (e.g., an honored combination of trips with the bid). This requires the proper application of the MidnightOffset to identify the current person"s days off (i.e., the person who made the bid)
WHEN - the run is completed
THEN - the run result reflects the proper application of the MidnightOffset in identifying the current person"s days off (i.e., the person who made the bid).
 

S-85338 - SCX - Add Midnight Offset to Set Condition Preference: Min Days On in a Row

For SCX, we have added a new parameter to the Global Midnight Offset Options: ApplyToRule_Pairing_MinDaysOn. This is added for all customers in their PbsSettings.XML file, within the existing MidnightOffsetOptions, alongside other parameters like ApplyToRule_Pairing_[...].
 

An upgrade script is required to add this new option to existing systems:

• Initial value for SCX will be one
• Initial value for ASAP will be one (so this will give ASAP the functionality they had previously requested, under the now-cancelled story S-83717)
• Initial value for all other customers will be zero
• Update Config Spreadsheet PbsSettings sheet
• Implement necessary c++ code for converting/setting the option (similar to other parameters like ApplyToRule_Pairing_[...]).
  
   

Modify the pairing-MinDaysOn rule to support the MidnightOffset:

Only if MidnightOffsetMinutes is non-zero and ApplyToRule_Pairing_MinDaysOn is TRUE. For comparison, refer to the Pairing-MinDaysOff and Pairing-MaxDaysOn rules, which already support the MidnightOffset. Add a unit test for the Pairing-MinDaysOn rule (currently non-existent), and include tests for the MidnightOffset. Update the Rules Reference Manual to describe the usage of the MidnightOffset global rule option for this rule.
 

Acceptance Criteria:

GIVEN - an Administrator
WHEN - viewing the Rule Editor, and selecting the "Global Rules"
THEN - the new parameter appears within MidnightOffsetOptions, with the initial value as described.

AND

WHEN - selecting the new parameter and clicking "Edit"
THEN - the value of the new parameter can be edited (using a checkbox), and if the value is changed, the system correctly remembers the change after logging out, and logging back in.

GIVEN - an administrator
WHEN - completing a Pairings run or Concurrent Pairing/Reserve run
THEN - the new parameter is set on CoreGlobalData, which is visible in the scheduler log file.

GIVEN - a customer with MidnightOffsetMinutes set to a non-zero value. ApplyToRule_Pairing_MinDaysOn is set to TRUE. The Pairing bid group "Pattern" is available. And a run for the customer that includes at least one aspect of the result (e.g., an honored combination of trips with a Set Condition Pattern bid) that requires the proper application of the MidnightOffset to the Min Days On portion of the pattern bid.
WHEN - the run is completed
THEN - the run results reflect the proper application of the MidnightOffset to the Min Days On portion of the pattern bid.
 

S-81513 - SCX - Customized Per Diem - Modification of the CrewPlan Pairings File Import

We clarified existing functionality of the import of a CrewPlanPairings file to read additional columns for Per Diem values (597-602) for Record type 1.

 SCX provides Per Diem Cash Values in the Pairing File as follows:

Per Diem is referenced in Record type 1 of the pairing details and utilizes columns 597-602, which is six characters.

Example using above image: 301.16

• Values in columns 597-599 represent dollars.
• Values in columns 600-602 represent cents.
   Note: NPBS does not calculate these values but only reads them.
• The decimal split occurs following column 600. For example: 100.099.

 Note: If columns 597-602 are missing or blank, assume no Per Diem.

The new "Per Diem" value is displayed below the Time Away From Base (TAFB) value for each pairing. Note: If possible, add the dollar sign. However, if this change is too complex, do not add.

In addition, the new "Per Diem" value also displays in the "Times" section for the Pairing details, and in the "Flights" details, specifically only in Section 2.

Nonetheless, the "Per Diem" value is available in the following report: the Pairings Report.

Happy Path Scenario:

1. Log in as an Admin and access the Admin UI.
2. Import a CrewPlanPairings file with Per Diem values.0.

Expected Results:

• The file import is successful.
• The "Per Diem" value displays for each pairing in the report, within the Pairing Details, and in the web app.  

Acceptance Criteria:

GIVEN - a SCX Planner

WHEN - importing a pairing file that contains Per Diem Values
THEN - the system imports the file, and populates the Per Diem values appropriately.

GIVEN - a SCX Planner
WHEN - the file that contains Per Diem Values is imported
THEN - the Per Diem values in the pairings under the TAFB values display.

GIVEN - a SCX Planner
WHEN - the file that contains Per Diem Values is imported
THEN - the Per Diem values in the generated reports (Pairings report) display. 

GIVEN - a SCX Bidder
WHEN - viewing pairing details in the WebApp that have Per Diem values
THEN - the values display in dollars and cents.
 

S-85332 - SCX - Pairing Import Length of Trip

For SCX, we updated the configuration spreadsheet, ensuring that the Pairing Import Length of Trip values are correctly configured to reflect the SCX Calendar Day ending at 0200. The values are now in days, and fields 593-596 have been updated accordingly.

 The image to the right shows the PRG file, where the Equivalent Limit Hours field has been repurposed to accommodate the trip length values.

Changes to here:

Nothing in the Pairing Details Change

Bidding is based on the number on the right (as indicated in the file they provide with pairing length). The pairing details (check marked area) do not change.

S-85992 - SCX - Removal of Biddable Reduced Regular Lines from Configuration

For SCX Bidders, we introduced a new method to remove the "Reduced Regular Line Bid" option from the User Type Options .XML file in two locations. Additionally, we created a new process for SCX Admins to remove the "Reduced Regular Line Bid" option from the Category Options .XML file (also in two locations).

We also remove the statistics related to the "Reduced Regular Line" from the following files:

1. Run Details Summary.txt (two statistics + one extra section)
2. New Run Details Summary.txt (two statistics).0.

Note: Update the Configuration spreadsheet.
 

Acceptance Criteria:

GIVEN - a SCX Bidder
WHEN - viewing the bid options
THEN - the Pairing Bid Group "Reduced Regular Line" no longer displays.

   

GIVEN - a SCX Admin

WHEN - viewing the run template

THEN - the credit window parameter related to the Reduced Regular Line window no longer displays.  

Acceptance Criteria: 

GIVEN - a SCX Admin
WHEN - viewing the Stats Report
THEN - the three highlighted items (Reduced Regular Line, Non Reduced Regular Line, and Reduced Regular Line Pilots) below are no longer visible to them.

Acceptance Criteria: 

GIVEN - a SCX Admin
WHEN - viewing the Dynamic Stats Report
THEN - the three highlighted items (Reduced Regular Line, Non Reduced Regular Line, and Reduced Regular Line Pilots) below are no longer visible to them.

S-87564 - SCX - Configuration RelaxIfLineCannotBeBuilt to FALSE

We added a change by setting the RelaxIfLineCannotBeBuilt in the Reserve-RequiredDayOffPattern to FALSE.

 Note:

• Update the configuration spreadsheet
• Upgrade script similar to data/upgrade/UpgradeFalconDb-1.631.pl   

Acceptance Criteria:

GIVEN - an SCX admin
WHEN - in the Rule Editor under Reserve-RequiredDayOffPattern
THEN - RelaxIfLineCannotBeBult is set to FALSE.

GIVEN - a SCX admin
WHEN - performing a run
THEN - the scheduler log file shows RelaxIfLineCannotBeBult set to FALSE. 

S-87653 - SCX - RestBeforeAndAfterPairings Rule

We added a parameter to the RestBeforeAndAfterPairings rule, called "ExcludeTrainingAbsences," with possible values of 0 or 1 (TRUE or FALSE). This parameter works the same as ExcludedAbsenceCodes but applies to all Absence codes flagged as training. Also, we enhanced the rule’s functionality to support this new parameter.

 For SCX, replace DomesticHomeRest with RestBeforeAndAfterPairings, and use the following values:

• MinutesAfter: 720
• MinutesAfterTheater: 720
• MinutesBefore: 0
• MinutesBeforeTheater: 0
• MinutesBetweenCDOs: 720
• AtLeastLastDutyLengthAfter: 0
• ExcludedAbsenceCodes: EMPTY
• ExcludeTrainingAbsences: 1.

 
 Note: 

• upgrade script
• update config spreadsheet
• update rules reference manual.
  
   

Acceptance Criteria:

GIVEN - a SCX Admin
WHEN - viewing the Rule Editor
THEN - the PairingDomesticHomeRestRule no longer displays
  

AND 
  

THEN - the RestBeforeAndAfterPairings rule, with the parameters listed in the description displays.

GIVEN - a SCX Admin
WHEN - performing a scheduler run for a scenario where behavior changes due to the ExcludeTrainingAbsences flag
THEN - the scheduler behaves correctly.

S-88058 - SCX - Add Vacation Slide Grouping

For SCX, we updated the configuration spreadsheet, ensuring that SCX is set to TRUE for the PilotAllowSlidesGroupingUpdate setting.

Acceptance Criteria:

GIVEN - a SCX admin
WHEN - in the configuration Absence codes tab

AND editing an Absence code

THEN - slide groupable and slide group label displays.

S-90033 - SCX - Add SUB MENU to FOLO BID on Bidder UI

For SCX, we created a new feature that allows users to select multiple FOLO bid options in priority order on the Bidder UI. Previously, the Bidder UI only allowed users to select one FOLO bid option at a time without prioritization.

SCX is now able to create multiple FOLO bids that are mutually exclusive. As PBS displays them in priority order, they appear as follows:
FOLO AM
FOLO PM
ECT...

NOT

 FOLO AM, FOLO PM

In addition, we created arrows to move FOLO bid groups up or down (image of arrows shown below). The FOLO groups always stay at the top. FOLO automatically prioritizes all FOLO bids, placing them at the top of the list, while any Pairing bid groups or Reserve bid groups move below. Note: With FOLO, users can also use a bid group with pre-configured instructions.
 

Acceptance Criteria:

GIVEN - a Bidder
WHEN - selecting FOLO options
THEN - multiple FOLO bids can be selected independently of each other.

AND

WHEN - placing other bid group types
THEN - all FOLO bid groups are forced to the top of the bid.

AND

WHEN - the priority or order of the FOLO bid groups needs to be changed
THEN - the arrows are used to move them up and down.

S-90876 - SCX - FOLO Export Modifications

We created a new method for generating the FOLO report to accommodate SCX-requested changes on how the FOLO bid group is created. While the data format does not change, the order in which the records display is updated. For example, multiple lines may appear for the same bidder, listed one below the other, with the FOLO Bid Groups ranked in the report according to their setup in the web app.

Previous FOLO report format:
 

Example: Bidder 6101 created following bid groups:

• Long Call First Out
• PM First Out
• PM Last Out
• AM First Out.
    

In this order, the report displays as below:

6101,224,20230501,20230531
6101,222,20230501,20230531
6101,226,20230501,20230531
6101,221,20230501,20230531 one person, and their list of preferences,
6102,228,20230501,20230531 then another person with their list of preferences
6102,222,20230501,20230531
6102,226,20230501,20230531
 6102,224,20230501,20230531

Acceptance Criteria: 

GIVEN - a SCX Administrator
WHEN - exporting the FOLO Bids
THEN - the FOLO Bid report displays in the format shown above.
 

S-91498 - SCX - Pre-Configure Midnight Offset Options

We have added new functionality for Midnight Offset, providing SCX with the following options:

 These options are editable by the customer after release, however, the initial release includes the following default settings, performed through an upgrade script:

• MidnightOffsetMinutes=120
• ApplyToRule_Pairing_DomicileRestWithTable=1
• ApplyToRule_Pairing_MaxDaysOn=1
• ApplytoRule_Pairing_MinDaysOff=1
• ApplyToRule_Pairing_NoSameDayTrips=1.

Note: The other two items (AOffAfterB and MaxDutyDaysPerBidPeriod) are set to 0, as SCX does not have those rules.
 

Furthermore, the corresponding items in the baseline scx/PbsSettings.XML file are also changed to reflect the initial values upon release, and the customer configuration spreadsheet is updated.

Acceptance Criteria:

GIVEN - an SCX Admin upgrades the database
WHEN - viewing the Rule Editor, selecting "Global Rules", and examining the "MidnightOffsetOptions"
THEN - the MidnightOffsetMinutes value is preconfigured to 120, and seven of the nine "ApplyToRule_Pairing_..." values are preconfigured to one. The exceptions, "ApplyToRule_Pairing_AOffAfterB" and "ApplyToRule_Pairing_MaxDutyDaysPerBidPeriod," remain set to zero, as SCX does not have the corresponding rules.

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

For SCX, we updated the Pairings Tab to properly filter Redeyes, SOR, and Charter pairings.

UAT - Redeyes

UAT - Charters 

UAT - SOR

TRUNK - Redeyes