Indicator for overriden aftersales conditions

[stinacarlstedt]

During a disruption (or for other reasons) the aftersales conditions in the original booking can be overriden, so that a NO_FLEX-ticket becomes MID or FULL_FLEX to allow the passenger to reach their final destination. Currently, there is no way to signal to a client that such an override has been activated. We propose an update to the AbstractBookingPart to allow the operator to pass information to the distributor or the end-client around this override.

[CGantert345]

• Indicating a changes aftersalescondition and changing the aftersales condition might be easier?

• changes need to be indicated

• using an array?

• the webhook should provide an information that there was a change

[stinacarlstedt]

Proposed modelling:

[stinacarlstedt]

Updates to RefundType and ExchangeableType, to include flag and initial condition. Breaking change from v 3.

[stinacarlstedt]

Intermediate solution:

• Leave ExchangeableType and RefundType as they are (string - enum YES, NO, WITH_CONDITION)
• Add an optional parallel structure with AfterSalesOverrideDetails, specifying that the conditions have been overriden and preserving the initial conditions (with additional optional information, such as validity if applicable, description text on the reason for the channels, etc)

[stinacarlstedt]

We should also review whether the term should be AfterSale or AfterSales - we use both currently. Later...

[ConscritNeuneu]

I think the correct term is aftersales but I'm not native.

[stinacarlstedt]

Update proposed to the webhook enum:

[jspetrak]

@CGantert345 to draft PR