Air_MultiAvailability excluded connections question

[dnabeast]

I'm try to do an Air_MultiAvailability call with connection inclusions/exclusions.
In the documentation it suggest that
'includedConnections' => ['PAR'],
will add xml to the call to set this option.
I expected it would do something like

<qualifiedConnectionOption>
	<connectionOption>
		<firstConnection>
			<location>PAR</location>
		</firstConnection>
	</connectionOption>
</qualifiedConnectionOption>

But it doesn't appear in the ->getLastRequest() nor does it seem to send that command in the request.

Is this something missing from my WSDL file?
Or a feature that was documented but not actually implemented?
Or just me missing something obvious?

What is the missing piece of the puzzle?

Thanks in advance.

[dnabeast]

I'm not sure if this is important but it's using MultiAvailability16.
The messageBody has a qualifiedConnectionOption which is an empty array.
It's also has a connectionOption that has my connection details within.
I'm wondering if the connection options are supposed to be contained with the qualifiedConnectionOption at that point.

[dnabeast]

I think there might be a bug in the way the initial multiple excluded connections were implemented.
When entering included connections it seems it understands a first connection and a second one. Meaning that you want this order of connections (so you don't double back)

The test for excluded connections seems to imply that the default behaviour is to exclude the first location followed by any optional second location.

This does not seem to exclude a second location unless the first location comes first.

In my particular problem I wanted flights to only connect via AKL in New Zealand. I had to exclude all the other airports.

This can be done in XML but what it required was a list of first locations.

I've written a hack for myself to use but I'm thinking about doing a pull request to patch this. The only problem is that It will required a new way of entering first locations and/or second ones. Obviously backwards compatibility is important but with MultiAvailability16 I think it doesn't work anyway.

[DerMika]

Hello,

I would suggest adding one or more new properties to be used solely by MultiAvailability 16+ messages, and keep the old behaviour for older messages (unless someone there are issues with those too).

I assume you've seen the examples in the code of how the library can deal with differences in message versions? (example: https://github.com/amabnl/amadeus-ws-client/blob/master/src/Amadeus/Client/RequestCreator/Converter/Fare/PricePNRWithBookingClassConv.php#L44)