[
https://issues.apache.org/jira/browse/OFBIZ-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Gray closed OFBIZ-431.
----------------------------
Resolution: Fixed
In rev. 526491 I've changed saveUpdatedCartToOrder to call cancelOrderItemNoActions when cancelling existing promos.
recreateOrderAdjustments seems to work fine when being called once per request (like for cancelling a single order item) but makes a mess when called repeatedly, that's why step 2 in my comment above was working fine as there was only one promo at that point.
I think there's a still a few issues to be fixed with editing orders:
1. Multiple order change emails are being sent out (I think one is sent for every orderItem status change)
2. I don't think all inventory reservations should be cancelled at the start, this puts the order to the back of the queue even if a orderItem didn't change during the edit.
3. Promo lines shouldn't appear to be editable in editorderitems.ftl as they can't actually be edited
4. Promos that apply before and after an edit shouldn't be cancelled and then recreated, it makes a mess of the order and puts the reservation to the back of the queue.
But anyway, this issue appears to be fixed so I'll close it and open another for the things mentioned above.
> Editting Order goes recursive with promotions...
> ------------------------------------------------
>
> Key: OFBIZ-431
> URL:
https://issues.apache.org/jira/browse/OFBIZ-431> Project: OFBiz (The Open for Business Project)
> Issue Type: Bug
> Components: order
> Affects Versions: SVN trunk
> Environment: N/A - clean default
> Reporter: Ray Barlow
> Assigned To: Jacopo Cappellato
> Priority: Critical
> Attachments: 431-1.patch
>
>
> With the standard demo data raise an order for admin with 1 GZ-1000 and 1 GZ-7000, 3 promotional products will be added to the order which is fine.
> Find and view the newly created order in the order application. Click on the edit link and then try to increase the order quantity of the GZ-1000 from 1 to 2, the system will thrash away for a while and then fail with a transaction error, timed out.
> Once the dust has settled you can see that the party has also been sent 100 +/-5 email notification changes, which is were I'm getting the feeling that recursion is the problem!
> Trying to cancel a line item can also cause the same effect, in general editting orders with promotions seems to cause lots of problems at the moment.
> PS: I'd advise this only gets tested on local development machines as the impact is quite an intense load on the server and can result in DoS style problems. That said I did execute this once on the "demo.dejc.com" server (sorry David) just to check it wasn't anything I'd changed, the admin account now has a lot of order change notifications (at least until the next reload of the site!).
> PPS: This can also be triggered via the customer facing site, when cancelling a line item from the order history page, bit of an exposure for live sites to DoS from malicious users.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Locked
