Scott,
Thanks. The issue is at http://issues.apache.org/jira/browse/OFBIZ-431 , if
anyone wants to know.
What about my questions on "Edits of SO/PO and edit history"? Anybody knows how it worked before
it broke?
I'll try to look into OFBIZ-431. Thanks for your pointers.
Jonathon
Scott Gray wrote:
There's already a couple of jira issues in there, just filter by
Critical and you should find most of them. From memory the loop is the
last seca you mentioned, recreateOrderAdjustments which also happens to
call cancelOrderItem so the seca gets fires again.
Jonathon -- Improov wrote:
I have a few small questions related to the bigger question in email
subject. I hope someone can answer those offhand. I hit a problem
while testing (infinite loop), so I can't explore this aspect of OFBiz
beyond the show-stopper.
How does ofbiz handle revisions to SOs and POs? Any change histories
kept?
I see that shipping information can be changed. Again, any change
histories kept? Is the "splitting preference" change reversible? I
changed an SO to allow for split but couldn't reverse that decision.
Any change histories for "Contact Information"?
Ok, I'm done with my questions. And now, to share what I found about
the infinite loop.
Before I investigate further and post to JIRA, I'm wondering if
someone can tell me quickly whether cancellation of order items for SO
is supposed to work?
To reproduce infinite loop, try ordering a PC001, then go to Order
module and bring up SO, then try canceling an order item.
Here's what I see as the contents of the loop (though I could be wrong
and those calls could be correctly repeated SO MANY TIMES, unlikely?):
SECA: cancelOrderInventoryReservation, triggered by rule on Service:
changeOrderItemStatus
SECA: recalcShippingTotal, triggered by rule on Service:
changeOrderItemStatus
SECA: recalcTaxTotal, triggered by rule on Service: changeOrderItemStatus
SECA: resetGrandTotal, triggered by rule on Service:
changeOrderItemStatus
SECA: checkOrderItemStatus, triggered by rule on Service:
changeOrderItemStatus
SECA: sendOrderChangeNotification, triggered by rule on Service:
changeOrderItemStatus
SECA: recreateOrderAdjustments, triggered by rule on Service:
cancelOrderItem
Jonathon
