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 <[EMAIL PROTECTED]> 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.
