Sales/Api/Data/OrderItemInterface typo in KEY_PRODUCT_OPTION constant

[iben12]

Description

The Magento\Sales\Api\Data\OrderItemInterface defines constants for all the keys the entity (OrderItem) contains. The constant KEY_PRODUCT_OPTION is defined as product_option, but the corresponding database field is named product_options (note the plural form). This mismatch prevents the application to find and unserialize the field, so the API does not return this data for items when requesting an order, despite the documentation states it should (see).

Fixed Issues (if relevant)

1. Custom options in sales order details missing devdocs#946

Manual testing scenarios

1. Send a request to the REST API endpoint of rest/V1/orders/{id}
2. See that the items array contains product items that include the product_option property

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-cicd2]

All committers have signed the CLA.

[iben12]

Looks like this breaks ProductOptionProcessor when working with OrderItemRepository.

Anyone has any clue how this should work?

[vrann]

@iben12 thanks for digging into this issue!

However, this is more of a documentation issue. Despite product options are declared on the interface they are not supposed to be returned in the serialized format from the Web API. The main reason is not all the clients will be able to parse and ineterpret PHP serialized string.

Instead, to retrieve them there is separate product options processing mechanism invoked from the
\Magento\Sales\Api\OrderItemRepositoryInterface::get method To retrieve the product options for the order item, please use GET V1/orders/items/:id request.

Closing this PR and raising internal issue related to returning product options from the OrderInterface::getItems as well.