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