Vendure: Order modification impossible (4 bugs)

[chladog]

Describe the bug
1.) Currently when I make any modification to Order, the "Preview changes" button is always disabled - this is UI bug as when I enable it via DevTools then the update works.
2.) Updates to addresses are not made, the payload of this update call is empty "updateShippingAddress": {}, "updateBillingAddress": {},
3.) When updating an order that has failed/cancelled payments then it's impossible to add additional payment, as the outstanding value does not match to order total. _The outstanding order amount (114800) should equal the unsettled OrderModifications total (10000)_
4.) If order contains promotion already and we change the order value, then the outstanding value is higher by value of this promotion (e.g. order have promotion "Discount 10%": -3€; we add surcharge 10€, now the outstanding value is 13€ instead of 10€ (applied promotion "dissapears").

Environment (please complete the following information):

• @vendure/core version: v0.18.3

[michaelbromley]

Thanks for the report. I was aware of at least the 4th issue.

For 1) - have you tried entering a value in the "note" input? It is required (though not really obviously so)

[chladog]

ad1) oh yes, that's it. Missed that as we have exactly same textarea in that section normally also called Note (Order customfield Note...) - maybe then not require it, or state its requirement somehow? :)

ad2) I've found out when I left address form opened and click "Preview changes" all changes are reverted in that form on the background (I guess patchValue or reset on the form is fired by this point) - so I believe the problem is not in preparation of payload (that's just a consequence), but in the form behavior itself.

[michaelbromley]

OK, those Admin UI-related issues were easy to fix. Now on to the harder bits:

3.) When updating an order that has failed/cancelled payments then it's impossible to add additional payment, as the outstanding value does not match to order total. The outstanding order amount (114800) should equal the unsettled OrderModifications total (10000)

Can you lay out the sequence of API calls which gets an order into this state? Is the Order still in the "ArrangingPayment" state when you attempt to modify?

[michaelbromley]

@chladog I've solved the other issues, I just can't figure out how to reproduce point 3. Can you advise?

[chladog]

@chladog I've solved the other issues, I just can't figure out how to reproduce point 3. Can you advise?

Steps to reproduce in this:

1. Create an order of value X and add _Authorized_ Payment
2. Make the payment fail somehow (Decline or Error), keep the order in PaymentAuthorized state
3. Modify the order the way that it changes its value - add Product of value Y
4. Now it prompts you to add new payment for outstanding amount - this amount _should_ be (X+Y) (as the AuthorizedPayment was cancelled and there are no "live" payments) however the system says outstanding amount is only Y. And now you are in dead end since you can't proceed from this state with
   The outstanding order amount (XY) should equal the unsettled OrderModifications total (Y)

[michaelbromley]

I think the part I am missing is

Make the payment fail somehow (Decline or Error), keep the order in PaymentAuthorized state

I have a test PaymentMethodHandler there the settlePayment() method fails (success: false). However, I notice that this _does not_ set the Payment state to "Error" or "Declined". In fact, I can't see any way to transition a Payment from "Authorized" to "Error" or "Declined".

Does your implementation use some custom code which allows this to occur?

[chladog]

Yes, didn't consider there is no way by default to transition to this state. (I have a custom rest endpoint where payment provider notify us on payment status-if it's declined or timeouts then we cancel that payment as it's transaction ID is not valid, but keep order alive and if customer wants he can create a new payment for another 24hours) - and this is the use case, where would modification be useful for us, if some non-techy customer calls us to that he will pay in person or by direct payment we want to be able to handle this scenario even for a case that there is need to modify the order.
^
That's just the context where you can see the issue.

Anyway for reproduction of the bug I believe changing a state of your payment to "Error" in DB will suffice and I guess there should be a check "isOrderSettled" before actual outstanding amount calculation.

[michaelbromley]

OK, that makes sense. In the case you describe then, do you really need to modify the order? Or just add a new payment whilst leaving the order as it is?

If so, then I think it makes sense to have a new feature which would allow more control over payments - e.g. ability to cancel payments, add new payments. Right now it is a bit rigid on the happy-path flow.

What do you think?

[chladog]

@michaelbromley For a normal case that is someone just wants to pay later then the modification is not needed (we just set up a new payment with the order and this is currently working for us). However sometimes happens that customer calls and decides to just come to pick it up (*and pay) on-site, or possibly wants to add something to order or telling us that he (autocomplete) entered wrong address and we need a way to modify shipping/contents/address.

*The feature of managing payments in admin would be great addon to this and also generally - for example customer's card gets declined, he doesn't want to go through whole order process again and want to pay directly by wiretransfer - we have some elderly customers and this is actually happening more often than you would expect).

[michaelbromley]

Got it. Once https://github.com/vendure-ecommerce/vendure/pull/539 is resolved then I'll also work on making the payments more flexible so it is easier to deal with more unusual payment flows like you described.

[chladog]

Also now order in state _Arranging additional payment_ cannot be cancelled, but I believe it should be possible.