Openfoodnetwork: Backoffice orders: Item counter accepts values higher than the available stock, which may lead to incorrectly charged orders

[filipefurtad0]

Description

It is possible to introduce a number of items above the available stock, when orders are placed in the backoffice. This may lead to charging of higher amounts than the amounts available for shipping, leading to discrepancies between the information seen in the backoffice and that which reaches the customer.

I think it's easier to see this in two parts:
1) the item counter in the backoffice orders
2) the creation of orders which charge the incorrect amount

Expected Behavior

1) The item counter should not accept values higher than the available stock, for that specific product.
2) The values charged in the order should match their actual value. If more was charged, then the order should have an orange-colored "Credit Owed" state, instead of green "Paid".

Actual Behaviour

1) If added in a stepwise manner, the item counter in backoffice orders accepts values higher than the available stock, for that specific product.
2) If unaware of 1) the user may place an order which charges value higher than its real cost

Steps to Reproduce

Part 1)

1. Set a product in an open order cycle with available stock = 2, for example.
2. Go to the Orders page and create a new order
3. First, add two items from that product
4. Then, add items to the order, one by one - see the gif - till you have 5 items, for example. Notice the counter works correctly if you try to add 10 items, when only two are available.

Part 2)

1. Add customer details. At this point, you may go back to "Order details" and click "Update and recalculate fees". Observe that the stock is updated, but the value of the order isn't.
2. Proceed to Payments and checkout, for example, with Stripe
3. Go back to Order Details -> although the order is shown as Complete, notice that the amounts from the purchased items and the actually charged amount not match: 2 items were available, 5 items were charged. In Bulk Order Management, check that the status of the order is all green: "Credit Owed" is not showing
4. If possible, check that the customers order confirmation includes 5 items, and not 2. The value for 5 items was charged.
5. Check the Stripe account and verify that the amount on the customers confirmation order was indeed charged.

Animated Gif/Screenshot

Part 1)

Part 2)

Workaround

• If the user notices that the order value does not match the amount to be charged, then the workaround would be to drop that order and start a new one
• Cancelling that order, returning the paid amounts to the customer, and placing another one

Severity

Proposing a bug-s3: a feature is broken but there is a workaround

Your Environment

• Version used: v3.4.5
• Browser name and version: Firefox 80
• Operating System and version (desktop or mobile): Desktop Ubuntu 20.04

Possible Fix

[brymut]

Hi, if no one has started checking this out, I'd like to give it a go.

[sigmundpetersen]

Thanks @brymut , please go ahead! 🎉
Don't hesitate to ask if you have any questions!

[brymut]

I've gone through the user guides and can confirm/reproduce the 2 parts of the problem reported. Now having a look through the code to try prototype a possible solution.

[brymut]

Hi @sigmundpetersen , I've started on a draft PR that I think can introduce some client-side validation to solve for part 1, but still need to work out part 2.

[filipefurtad0]

While testing PR #6098 I've found it to be still possible, to add items above available stock, and trigger the whole fail cascade of orders with wrong values by typing stock values (instead of using the arrows):

There was already an improvement so, maybe severity could be lowered?