Description
When you add a tracking code using the REST API, Magento doesn't throw an error if you try to add a tracking code for a non-existing order. Take the following example:
{
"entity": {
"order_id": 20,
"parent_id": 12,
"track_number": "string",
"title": "string",
"carrier_code": "custom"
}
}
In the above example, there is no order with ID '20' in my database. However, I have an order with id '19' that has a shipment with ID '12'. So posting the above to the REST API will not throw an error. Instead it will return something similar to this:
{
"order_id": 20,
"created_at": "2016-12-12 13:37:57",
"entity_id": 12,
"parent_id": 12,
"updated_at": "2016-12-12 13:37:57",
"weight": null,
"qty": null,
"description": null,
"track_number": "string",
"title": "string",
"carrier_code": "custom"
}
I came across this 'feature' when a 3rd party was trying to add tracking codes to the Magento 2 API, but they accidentally used the increment ID instead of the order ID
Preconditions
- Magento 2.1.2
Steps to reproduce
- Create some orders where the increment ID is not equal to the order ID (not necessarily, but it illustrates the problem).
- Give on of the orders a shipment so you have a valid shipment ID voor the parent_id in the request.
- Create an API-request with a non-existing order-ID, but the existing shipment ID.
Expected result
- I would expect the API to return an error message like 'order not found' or something.
Actual result
- It creates the tracking code on to a shipment that does not match to any order (yet).
The big problem with this is as soon as the non-existing order gets created. In that case you have a tracking number that matches with an order and a shipment, but those shipment and order do not match with each other.
This was the case in my scenario, where the shipment tracking code would show up in the 'Comments History' panel, but not on any of the actual shipments that were linked to the order. At the same time, the order that should have the tracking code didn't have the comment, but it had the tracking code in the shipment. But this was more because at that moment the increment ID and entity ID of the shipments were the same (inc id #13 was entity id 13).
As soon as increment ID's and entity ID's of orders / and or shipments are not 'the same', using the increment ID in the API would give unexpected results.
I think an extra check on the API could prevent a lot of errors:
- Check if order_id exists.
- Check if parent_id is actually a shipment of order_id.