Can SOs and POs be edited, and if so, any change histories for edits of SOs and POs?
Locked
 
|
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 |
|
|
Regarding your "infinite loop", there is no loop.
Each of those services are being called because the service changeOrderItemStatus ran (and certain conditions for each of the SECAs were met) --- Jonathon -- Improov <[hidden email]> 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 > |
Re: Can SOs and POs be edited, and if so, any change histories for edits of SOs and POs?
|
|
In reply to this post by jonwimp
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 > |
|
|
In reply to this post by cjhowe
Chris,
Er, ok, to correct myself, I meant to say that there's an infinite loop possibly caused by cyclic dependencies in the SECAs. So suppose we have these events: A. Postman rings my doorbell B. I answer the front door C. My dog growls D. Postman leaves my front door E. I close front door and get back to my chores F. My dog goes back to his toys Then consider these SECAs: 1. A triggers B and C 2. C triggers D 3. D triggers E and F 4. E and F triggers A You don't encounter this infinite... erm... execution of this set of services? This... "loop" thing? I pretty sure cancellation of order items in an SO doesn't complete execution. Jonathon Chris Howe wrote: > Regarding your "infinite loop", there is no loop. > Each of those services are being called because the > service changeOrderItemStatus ran (and certain > conditions for each of the SECAs were met) > --- Jonathon -- Improov <[hidden email]> 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 >> > > |
|
|
What you explained was this though...
A=changeOrderItemStatus B=cancelOrderInventoryReservation C=recalcShippingTotal D=recalcTaxTotal E=resetGrandTotal F=checkOrderItemStatus G=sendOrderChangeNotification H=recreateOrderAdjustments I=cancelOrderItem A triggers B & C & D & E & F & G H triggers I is this incomplete? > >> 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 > |
|
|
Chris,
Erm. Yeah, it looks incomplete to me. Sorry! Jonathon Chris Howe wrote: > What you explained was this though... > > A=changeOrderItemStatus > B=cancelOrderInventoryReservation > C=recalcShippingTotal > D=recalcTaxTotal > E=resetGrandTotal > F=checkOrderItemStatus > G=sendOrderChangeNotification > H=recreateOrderAdjustments > I=cancelOrderItem > > A triggers B & C & D & E & F & G > H triggers I > > is this incomplete? > >>>> 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,
What I just repeated back to you is linear. Would you care to share the service call that is showing it looping? It doesn't appear to be listed there. --- Jonathon -- Improov <[hidden email]> wrote: > Chris, > > Erm. Yeah, it looks incomplete to me. Sorry! > > Jonathon > > Chris Howe wrote: > > What you explained was this though... > > > > A=changeOrderItemStatus > > B=cancelOrderInventoryReservation > > C=recalcShippingTotal > > D=recalcTaxTotal > > E=resetGrandTotal > > F=checkOrderItemStatus > > G=sendOrderChangeNotification > > H=recreateOrderAdjustments > > I=cancelOrderItem > > > > A triggers B & C & D & E & F & G > > H triggers I > > > > is this incomplete? > > > >>>> 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 > > > > > > |
|
|
Chris,
This is what Scott wrote on OFBIZ-431: "The infinite loop occurs when the cancelOrderItem service is called on an order containing promo order items. There is a seca on the service which calls recreateOrderAdjustments, which in turn iterates through all the promo items and calls cancelOrderItem on them, and on we go into the loop." I'd guess that Scott meant there's "a seca on the service [cancelOrderItem] which calls [service] recreateOrderAdjustments". I'd further guess (no, Scott stated this, actually) that the service recreateOrderAdjustments calls (aka trigger?) cancelOrderItem. So, if recreateOrderAdjustments is event A and cancelOrderItem is event B, I'd say A triggers B, which in turn triggers A. Let's see, here's what I wrote: 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 I suppose I should've included a final line like this: SimpleMethod.call-service: recreateOrderAdjustments (OrderServices.xml line 473) calls Service cancelOrderItem ? Sorry? :P Please? I must be tired when I wrote the above "contents of the loop". So it's not exactly a loop. Jonathon Chris Howe wrote: > Jonathon, > > What I just repeated back to you is linear. Would you > care to share the service call that is showing it > looping? It doesn't appear to be listed there. > > --- Jonathon -- Improov <[hidden email]> wrote: > >> Chris, >> >> Erm. Yeah, it looks incomplete to me. Sorry! >> >> Jonathon >> >> Chris Howe wrote: >>> What you explained was this though... >>> >>> A=changeOrderItemStatus >>> B=cancelOrderInventoryReservation >>> C=recalcShippingTotal >>> D=recalcTaxTotal >>> E=resetGrandTotal >>> F=checkOrderItemStatus >>> G=sendOrderChangeNotification >>> H=recreateOrderAdjustments >>> I=cancelOrderItem >>> >>> A triggers B & C & D & E & F & G >>> H triggers I >>> >>> is this incomplete? >>> >>>>>> 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 >>> >> > > |
|
|
In reply to this post by Scott Gray
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 >> > > |
|
|
In reply to this post by jonwimp
--- Jonathon -- Improov <[hidden email]> wrote: > I suppose I should've included a final line like > this: > > SimpleMethod.call-service: recreateOrderAdjustments > (OrderServices.xml line 473) calls Service > cancelOrderItem > > ? > There ;-) that's a loop. There should be two ways to at least put a bandaid on it (and it may actually fix it entirely). You can either check that the order item isn't currently canceled or you can call the java method directly so that the SECA won't trigger. both solutions are attached. A third way is to make a second cancel order item that does the exact same thing but by a different name. I would think this redundancy is less desirable than the other two. |
Re: Can SOs and POs be edited, and if so, any change histories for edits of SOs and POs?
|
|
I did try option 3 a while back but there are still other problems with
the code, for example I think an order notification is triggered as a seca on cancelOrderItem and also on changeOrderItemStatus which results in a ton of emails being generated. > There ;-) that's a loop. There should be two ways to > at least put a bandaid on it (and it may actually fix > it entirely). > > You can either check that the order item isn't > currently canceled or you can call the java method > directly so that the SECA won't trigger. > > both solutions are attached. > > A third way is to make a second cancel order item that > does the exact same thing but by a different name. I > would think this redundancy is less desirable than the > other two. > |
|
|
Ahh...I see now. recreateOrderAdjustments is doing a
sort of fake cancellation but using the big boy services to accomplish it. Perhaps it would be better to have the simple-method update the OrderItem and create the OrderItemStatus on it's own in that iteration section and not bother with the service calls (with a comment as to why it's being done this way)? Sound good? --- Scott Gray <[hidden email]> wrote: > I did try option 3 a while back but there are still > other problems with > the code, for example I think an order notification > is triggered as a > seca on cancelOrderItem and also on > changeOrderItemStatus which results > in a ton of emails being generated. > > There ;-) that's a loop. There should be two ways > to > > at least put a bandaid on it (and it may actually > fix > > it entirely). > > > > You can either check that the order item isn't > > currently canceled or you can call the java method > > directly so that the SECA won't trigger. > > > > both solutions are attached. > > > > A third way is to make a second cancel order item > that > > does the exact same thing but by a different name. > I > > would think this redundancy is less desirable than > the > > other two. > > > > |
Re: Can SOs and POs be edited, and if so, any change histories for edits of SOs and POs?
|
|
But that wouldn't that only work if the promo line is to be reapplied?
If the promo no longer applies to the order cancelOrderItem and everything that goes with it needs to be used. I can't see why the cart is reloaded when you already have a cart in hand, why not compare the updated cart to the order and update items as necessary rather than rebuilding the adjustments from scratch? Chris Howe wrote: > Ahh...I see now. recreateOrderAdjustments is doing a > sort of fake cancellation but using the big boy > services to accomplish it. > > Perhaps it would be better to have the simple-method > update the OrderItem and create the OrderItemStatus on > it's own in that iteration section and not bother with > the service calls (with a comment as to why it's being > done this way)? > > Sound good? > > --- Scott Gray <[hidden email]> wrote: > > >> I did try option 3 a while back but there are still >> other problems with >> the code, for example I think an order notification >> is triggered as a >> seca on cancelOrderItem and also on >> changeOrderItemStatus which results >> in a ton of emails being generated. >> >>> There ;-) that's a loop. There should be two ways >>> >> to >> >>> at least put a bandaid on it (and it may actually >>> >> fix >> >>> it entirely). >>> >>> You can either check that the order item isn't >>> currently canceled or you can call the java method >>> directly so that the SECA won't trigger. >>> >>> both solutions are attached. >>> >>> A third way is to make a second cancel order item >>> >> that >> >>> does the exact same thing but by a different name. >>> >> I >> >>> would think this redundancy is less desirable than >>> >> the >> >>> other two. >>> >>> >> > > > |
|
|
My eyes are getting tired and I'm not positive I'm
reading that right. Are you suggesting that there are two issues going on? One of recursion and one of inefficiency? Or are you suggesting that even if the recursion is handled, the logic bringing you to the end result is still wrong? If it's two separate issues, can we address the critical of recursion now and save the minor issue of efficiency for later? If the end result is inaccurate, I think I'm in your boat with the limited time. --- Scott Gray <[hidden email]> wrote: > But that wouldn't that only work if the promo line > is to be reapplied? > If the promo no longer applies to the order > cancelOrderItem and > everything that goes with it needs to be used. I > can't see why the cart > is reloaded when you already have a cart in hand, > why not compare the > updated cart to the order and update items as > necessary rather than > rebuilding the adjustments from scratch? > > Chris Howe wrote: > > Ahh...I see now. recreateOrderAdjustments is > doing a > > sort of fake cancellation but using the big boy > > services to accomplish it. > > > > Perhaps it would be better to have the > simple-method > > update the OrderItem and create the > OrderItemStatus on > > it's own in that iteration section and not bother > with > > the service calls (with a comment as to why it's > being > > done this way)? > > > > Sound good? > > > > --- Scott Gray <[hidden email]> wrote: > > > > > >> I did try option 3 a while back but there are > still > >> other problems with > >> the code, for example I think an order > notification > >> is triggered as a > >> seca on cancelOrderItem and also on > >> changeOrderItemStatus which results > >> in a ton of emails being generated. > >> > >>> There ;-) that's a loop. There should be two > ways > >>> > >> to > >> > >>> at least put a bandaid on it (and it may > actually > >>> > >> fix > >> > >>> it entirely). > >>> > >>> You can either check that the order item isn't > >>> currently canceled or you can call the java > method > >>> directly so that the SECA won't trigger. > >>> > >>> both solutions are attached. > >>> > >>> A third way is to make a second cancel order > item > >>> > >> that > >> > >>> does the exact same thing but by a different > name. > >>> > >> I > >> > >>> would think this redundancy is less desirable > than > >>> > >> the > >> > >>> other two. > >>> > >>> > >> > > > > > > > > |
Re: Can SOs and POs be edited, and if so, any change histories for edits of SOs and POs?
|
|
I'm saying your suggested fix of for the recursion won't work because
the current logic requires that the promo items be cancelled completely (inventory reservations etc.) in case the promo is not reapplied to the order. I guess you could do everything that cancelOrderItem does, but i'm sure it won't work because I tried using a new service def to call the cancelOrderItem method and the result was a mess of order items. I think the whole process needs a review. Regards Scott Chris Howe wrote: > My eyes are getting tired and I'm not positive I'm > reading that right. > > Are you suggesting that there are two issues going on? > One of recursion and one of inefficiency? Or are you > suggesting that even if the recursion is handled, the > logic bringing you to the end result is still wrong? > > If it's two separate issues, can we address the > critical of recursion now and save the minor issue of > efficiency for later? > > If the end result is inaccurate, I think I'm in your > boat with the limited time. > > > > --- Scott Gray <[hidden email]> wrote: > > >> But that wouldn't that only work if the promo line >> is to be reapplied? >> If the promo no longer applies to the order >> cancelOrderItem and >> everything that goes with it needs to be used. I >> can't see why the cart >> is reloaded when you already have a cart in hand, >> why not compare the >> updated cart to the order and update items as >> necessary rather than >> rebuilding the adjustments from scratch? >> >> Chris Howe wrote: >> >>> Ahh...I see now. recreateOrderAdjustments is >>> >> doing a >> >>> sort of fake cancellation but using the big boy >>> services to accomplish it. >>> >>> Perhaps it would be better to have the >>> >> simple-method >> >>> update the OrderItem and create the >>> >> OrderItemStatus on >> >>> it's own in that iteration section and not bother >>> >> with >> >>> the service calls (with a comment as to why it's >>> >> being >> >>> done this way)? >>> >>> Sound good? >>> >>> --- Scott Gray <[hidden email]> wrote: >>> >>> >>> >>>> I did try option 3 a while back but there are >>>> >> still >> >>>> other problems with >>>> the code, for example I think an order >>>> >> notification >> >>>> is triggered as a >>>> seca on cancelOrderItem and also on >>>> changeOrderItemStatus which results >>>> in a ton of emails being generated. >>>> >>>> >>>>> There ;-) that's a loop. There should be two >>>>> >> ways >> >>>>> >>>>> >>>> to >>>> >>>> >>>>> at least put a bandaid on it (and it may >>>>> >> actually >> >>>>> >>>>> >>>> fix >>>> >>>> >>>>> it entirely). >>>>> >>>>> You can either check that the order item isn't >>>>> currently canceled or you can call the java >>>>> >> method >> >>>>> directly so that the SECA won't trigger. >>>>> >>>>> both solutions are attached. >>>>> >>>>> A third way is to make a second cancel order >>>>> >> item >> >>>>> >>>>> >>>> that >>>> >>>> >>>>> does the exact same thing but by a different >>>>> >> name. >> >>>>> >>>>> >>>> I >>>> >>>> >>>>> would think this redundancy is less desirable >>>>> >> than >> >>>>> >>>>> >>>> the >>>> >>>> >>>>> other two. >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |