Added function definition for setAdditionalInformation in \Magento\Sa…

[koenner01]

…les\Api\Data\OrderPaymentInterface

Description

When trying to run a paid order through a \Magento\Framework\Webapi\ServiceOutputProcessor it will fail because the 'additional_information' data has no corresponding setter defined in the interface.

The ServiceOutputProcessor tries to serialize the order object based on the (api) interfaces. When it reaches the serialization of the Payment object in the order the processor will fail when the object has data for 'additional_information' (normally this contains the payment method name).

The Magento\Sales\Api\Data\OrderPaymentInterface should contain a setAdditionalInformation function definition which will be implemented by the setAdditionalInformation function defined in Magento\Payment\Model\InfoInterface

Fixed Issues (if relevant)

1. Magento\Sales\Api\Data\OrderPaymentInterface is missing a setter for 'additional_information' data #13222

Manual testing scenarios

1. See description and testing scenario in original issue Magento\Sales\Api\Data\OrderPaymentInterface is missing a setter for 'additional_information' data #13222

Contribution checklist

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• All automated tests passed successfully (all builds on Travis CI are green)

[magento-engcom-team]

@koenner01 thank you for contributing. Please accept Community Contributors team invitation here to gain extended permissions for this repository.

[koenner01]

@magento-engcom-team I accepted the invite, but I removed myself immediately after (because the spammage of notifications was going overboard). Thanks for the offer though!

[centerax]

why is it on hold? can this be merged?

[rogyar]

At the moment we cannot accept the solution since it causes backward compatibility issues (see http://devdocs.magento.com/guides/v2.0/contributor-guide/backward-compatible-development/). Thank you for the collaboration.

[hostep]

@rogyar: if the PR was targeted towards the 2.3-develop branch, would it then be accepted?

And BiC can't be ignored in this case? Since this PR actually fixes a serious oversight.

[rogyar]

@hostep the issue is going resolved on the implementation level in further releases. Unfortunately, we cannot ignore BC in this case since it might cause problems with the existing installations. If some 3rd party extension implements the interface, we get the installation broken.

[hostep]

I think if it's a bug, BC can be ignored and if it's a new feature, the BC rules should be adhered. But whatever, we've patched in in our installation, others might then still run into this bug until it's fixed properly in a couple of months/years.