Magento2: Admin product save overwrites inventory qty even when it is unchanged

[cykirsch]

Preconditions

1. As far as I know, this issue exists in all versions of Magento 2.x (and 1.x)

Steps to reproduce

1. Go to the Manage Product admin page for SKU-123.
2. Change the Qty to 10 and save. The reloaded page will show Qty 10.
3. In a new tab, either admin or frontend, place a new order for Qty 2 of SKU-123.
4. At this point, if you query the cataloginventory_stock_item table, the qty will be 8, because 2 out of 10 have been purchased.
5. Back on the original tab (Manage Product admin page), without making any changes, click Save.

Expected result

1. Because no changes were made to the qty on the admin product page, no changes should be made to the qty in the database. Therefore, when the page loads after saving, the qty field should display 8.

Actual result

1. The exact value in the Qty field on the admin product page (in the above example, 10) is saved to the database. Therefore, when the page loads after saving, the qty field displays 10.

Further details from past experience

Magento 1 & 2 do both implement a qty_correction mechanism on the Stock\Item. Unfortunately, this only accounts for any changes made to the database since the Stock Item object was loaded. This object is obviously not loaded until the request is initiated by clicking the Save button.

Instead of accounting for how much the qty has changed since the Stock Item object was loaded, Magento should really account for how much the qty has changed since the product page was loaded.

How we fixed the issue in our M1 store

...and we will do this in our M2 store as well if Magento doesn't implement a fix

Add an additional (hidden) field to the admin product page that holds the original_inventory_qty. In the save request, we then set qty_correction = new - original, where new and original both come from the admin inputs. Magento\CatalogInventory\Model\ResourceModel\Stock\Item::_prepareDataForTable() will take it from here and change that qty_correction to a qty +/- db statement.

[Andrii-Deineha]

@cykirsch Hi, thank you for your submission. The Magento 2 GitHub repository is used to capture code and documentation issues. Questions should be posted to a question and answer site, such as Stack Exchange and the Magento Forums, where Magento community members can quickly provide recommendations and advice.

[korostii]

@Andrii-Deineha,
When you write a question, there would be a question mark at the end. Looks like the following: ?.
There isn't one in this issue report, which means: there is no question.
Thus it must be either a bug or a requested improvement.

You could, of course, argue that this too complicated of an issue, and that you might need to introduce stock movements into the inventory module in order to fix it for good and move this task to some bottom drawer.

But, nevertheless, the behavior is indeed strange and it's a valid issue. Please don't dismiss it using an irrelevant reason.

[magento-engcom-team]

@cykirsch, thank you for your report.
This seems to be correct Magento behavior. Please refer to the Community Forums or the Magento Stack Exchange site for advice or general discussion about this.
Otherwise you may submit Pull Request with the suggested changes.

[jmonschke]

@magento-engcom-team If I understand you correctly, you are saying that it is a feature of Magento that when you have inventory tracking enabled, you should never trust the inventory numbers stored in Magento?

Every time you save a product from the adminhtml section of the site, if there is an order for that product that happens before the admin page for the product is loaded and before it is saved, then you will have inaccurate inventory numbers.

[ghost]

@magento-engcom-team I don't understand why you would say it "seems to be correct Magento behavior." Is there a reason that you know of that it should behave this way? Perhaps there is some feature we don't grok that is obvious to you. jmonsche's example of an order being placed just before an admin user clicks the save button on the admin product page is an extremely worrisome behavior.

Or perhaps you just meant to say it is a sort of "won't fix" issue where you recognize it could be iffy behavior but the Magento org's priorities are elsewhere?

That being said the suggestion to submit a PR is perfectly reasonable, and the person who raised the issue seems like they have a solution, or a partial solution, and they could do that.

[magento-engcom-team]

Hi All,
Thank you for your feedback and research. If you would like to change this behavior, feel free submit a pull request with proposed changes.
We are closing the ticket as non-issue for now.

[korostii]

seems to be correct Magento behavior
non-issue

You guys must be having some special definitions for the word "issue" and "correct".

If you would like to change this behavior, feel free submit a pull request with proposed changes.

What's the point if the PR will have a great risk of being rejected because "This seems to be correct Magento behavior" already?

Does this non-issue label means that the issue is valid, reproducible, yet your company decided not to put any resources up to resolving it (or even bothering to reproduce)? That okay IMHO but should worded explicitly in order not to create any confusion.

Otherwise it's hard to understand whether the issue is valid whatsoever and whether there are any bugs to fix here.