Prestashop: Invalid product prices after order edit (eg. tracking number, address)

[kpodemski]

Describe the bug

When you edit shipping in existing order, PrestaShop resets product prices.

Expected behavior

Of course product prices should always stay same when you edit shipping method.

Steps to Reproduce

Steps to reproduce the behavior:

1. Set product price (doesn't matter which product) to 1000 USD/EUR/PLN (doesn't matter)
2. Order it, select paid shipping.
3. Finish order.
4. Edit product price from 1000 to 1500 (for example sale-offer has ended)
5. Go to order in back-office, see that product price is still 1000 (OK)
6. Now edit shipping method in this order. You'll see that price of product changed to 1500 (NOK)...

Issues:

• invalid product prices
• invalid invoices

Additional information

• PrestaShop version: 1.7.7.0
• PHP version: N/A

[kpodemski]

Same issue when you edit existing customer address in order, even alias.

Notes

Problematic method:
https://github.com/PrestaShop/PrestaShop/blob/develop/src/Adapter/Order/OrderAmountUpdater.php#L251

IMO we shouldn't base on Cart prices as every time you get instance of Cart prices for products are fresh and up to date, in Order in most scenarios we need to base on historical data from OrderDetail

[hibatallahAouadni]

Hello @kpodemski

I managed to reproduce your issue only with PS1.7.7.0 (I didn't managed to reproduce with PS1.7.6.9 & PS1.7.6.7), see the attached screen record below:

https://drive.google.com/file/d/1ZhdqVOhzGUD-ce-_G3cBHoA_oSiWVis4/view

I’ll add this to the debug backlog so that it’s fixed.
If you have already fixed it on your end or if you think you can do it, please do send us a pull request!

Thanks!

[kpodemski]

@hibatallahAouadni I'm not sure if it's Minor, I can imagine dozen scenarios where this issue can lead us to some serious issues related to invoices and order processing as an overall

[kpodemski]

@hibatallahAouadni

I changed title to be more precise.

This issue is more serious as many "order edit" actions are causing price refresh, for example:

• inserting tracking number
• changing carrier entirely
• editing customer address

[hibatallahAouadni]

Thanks @kpodemski

I changed the severity to Major, this bug impact the invoice too.

Thanks!

[SimonGrn]

kpodemski product

🤣

[MatShir]

hi @kpodemski,
Your issue is a bit related to this https://github.com/PrestaShop/PrestaShop/issues/22192, the order cart reloads and recalculates at any modifications. What do you think of lock the price as specific prices when the order is considered as paid or a invoice is generated? :thinking:

Not updating the cart when editing the address is legit. I'm wondering if it has to go a bit futher

[kpodemski]

@MatShir

Not updating the cart when editing the address is legit. I'm wondering if it has to go a bit futher

Actually @jolelievre has a good scenario when in some cases we need to update prices, because tax rules are different (country is different) - this is very rare scenario but it has to be checked, that's for sure.

Your issue is a bit related to this #22192, the order cart reloads and recalculates at any modifications.

Yes, it is related.

What do you think of lock the price as specific prices when the order is considered as paid or a invoice is generated?

I was discussing it with @jolelievre some time ago that in my opinion we shouldn't allow some modifications in order if there's an invoice or order is shipped, it's very complex topic tho.

Basically from my point of view most actions on order shouldn't update prices at all, which points me to conclusion that we should have some kind of forceUpdateOrderAmount method which is executed only in very specific scenarios.

cc @jolelievre

[jolelievre]

I'm gonna make a POC to fix this issue and see where behat tests fail, then we can decide for each use case what we should do, but basically we all agree that we shouldn't force product prices so:

• product prices should depend on OrderDetail values saved at the moment the order was created
• the thing is we rely on Cart for all computations, so I'm gonna try and see if I can modify it so that it's able to fetch prices from OrderDetail when it's associated to an Order
• if I manage to do this we could maybe even remove our current use of SpecificPrice in order overriding management

Then another question will rise about CartRules, should we update them at each modification or not? I'd like it very much if we can have a generic behaviour for each use case because if we don't this is gonna create so many inconstencies like:

• when I change the number in my street product prices shouldn't change
• but if I change the country it should..
• oh but the discount has been modified it should be updated
• oh but not in this case, I want to keep the initial one..

This could quickly become a nightmare ^^ But I'll know a bit more after the initial POC

[kpodemski]

when I change the number in my street product prices shouldn't change
but if I change the country it should..
oh but the discount has been modified it should be updated
oh but not in this case, I want to keep the initial one..

You're right, it's tricky, especially in these two:

oh but the discount has been modified it should be updated
oh but not in this case, I want to keep the initial one..

when someone already placed an order, I'm not sure if we should apply any other CartRules to it, maybe it's something to discuss with merchants, merchant can easily create custom discount or change product price manually to have full control over order and prices 🤔 if someone wants to add 1 extra unit of product after placing an order to match some discount we don't really need to recalculate everything, we can left it to merchant as it was in 1.6 and in previous 1.7 versions, right?

[jolelievre]

Yeah but it seems unfair that a discount that would have been applied on the FO is not applied in the BO after modification (like a discount for minimum amount for example), and the merchant is not a machine and doesn't necessarily know all the discount rules applied in the shop

Besides there is a technical issue behind this, that cart frequently calls CartRule::autoAddToCart and CartRule::autoRemoveFromCart and it's not possible to disable it in all cases Even if it were internally in the core commands, it's still called in simple method like $cart->getProducts() which can be called in module (from the BO side and, scarier, even from the FO side). So it would be more risky to decide to ignore this behaviour, and considering the complexity of its integration today it's not possible to remove it or modify it too much.

So instead we took the other road, the cart rules are automatically and systematically added when you modify the order so that it remains consistent with the rules set in the Shop. BUT the merchant can always remove them from the order if he doesn't wan it applied, then the order is updated accordingly and the removal action is saved via OrderCartRule thus preventing it from being automatically added again even when CartRule::autoAddToCart is called.

[radioeventos]

If edit a product, carrier price disapear and does not match with payment. Must change by DB. Does not well.
This is a very serious bug for a production version. Rounding does not work correctly either, on the screen the product line shows one amount and the total number of products shows another.

[MatShir]

@radioeventos could share with us all your steps to produce this bug? We need to be sure your issue is the same as this ticket or related to a new one :smile:

[radioeventos]

[agroundworld]

when I change the number in my street product prices shouldn't change
but if I change the country it should..
oh but the discount has been modified it should be updated
oh but not in this case, I want to keep the initial one..

You're right, it's tricky, especially in these two:

oh but the discount has been modified it should be updated
oh but not in this case, I want to keep the initial one..

when someone already placed an order, I'm not sure if we should apply any other CartRules to it, maybe it's something to discuss with merchants, merchant can easily create custom discount or change product price manually to have full control over order and prices 🤔 if someone wants to add 1 extra unit of product after placing an order to match some discount we don't really need to recalculate everything, we can left it to merchant as it was in 1.6 and in previous 1.7 versions, right?

I don't know much about the specifics of how this is coded to work, but if it is heavily situation dependent with many unknowns, you might consider an option to allow the end user to decide whether or not the price needs updating based off the changes they are making.

[radioeventos]

I don't know much about the details of how it's coded to work, but if it depends heavily on the situation with many unknowns, you may consider an option to allow the end user to decide whether or not the price should be updated based on the changes they're making.

I understand it less and less, instead of making the job easier for the trader, it gets complicated.
The final decision on prices is of the merchant, who has to square accounts between what is paid by the customer and the final order. If item prices can be changed, why is the carrier price automatic?
If you design a store without the trader's point of view, we go wrong. There are many circumstances by which an order may have to be changed:
Having to exchange one product for another, having to add or remove products, error in selecting the section by the customer... In all these cases it would not have to be reset or recalculate the shipping costs if we don't need it. If you want to do there is the option to do it manually, but being automatic is a serious mistake, because on the invoice they're not going to square the amounts paid and that's very serious for accounting.
Every time I see Prestashop opting more for design than real usability when programming and that's not the right path.
This is just one of the dozens of bugs that the latest version has, some dragged from previous versions and instead of fixing things, with each version there are new drawbacks. Even its own modules are not optimized for the new version, there are serious errors in the translation system, cache, multistore... It looks more and more visually like Ebay: every page in BO has a different layout and you get lost in finding things.

[ttoine]

Hello, some people in this discussion are not respecting the Code of Conduct .
Please calm down, being friendly and respectful is the key. Nobody want to work with agressive people.

[radioeventos]

Hello, some people in this discussion are not respecting the Code of Conduct .
Please calm down, being friendly and respectful is the key. Nobody want to work with agressive people.

Very interesting your contribution. Look at another wonder of the new version when I try to write down a refund of a payment: