When a basket is closed all orders are set to status 'ordered', if reopened they are all set to 'new', however if some orderlines are receipted and the basket subsequently reopened and again closed (e.g. to cancel some orders) although the order has copies received set, a datereceived and a link to an invoice it status reverts to new 9after reopen) or on order (after close) which does not reflect its true state. These operations should not include completed lines in their status updates
Created attachment 43682 [details] [review]
To test create a basket with a number of orders close. receive one of the orders,
reopening and closing the basket will change the received order status as outlined in the bug report.
Apply the patch. Receive another order in the basket again reopen and close the basket. Note that the status of the completed order is not overridden by these operations
Without the patch :
I have added a new baskest with 2 orders, closed this basket, received one of the order. Orders status for this basket are "complete" and "ordered". I have re-opened the basket : ordered status are both "new".
With the patch :
I redone exactly the same stages, but afer reopening the basket, ordered status are "complete" and "ordered".
Koha Team Lyon3 - is this a 'sign off'? :)
Yes, this is signed off but I tried to sign it with a sandbox 15 mn ago and nothing happens so far...
I will switch the status - we can add the line in QA if it doesn't appear.
Created attachment 44551 [details] [review]
[PASSED QA] Bug 15036: Do not overwrite complete status in basket ops
Reopening or closing a basket should preserve the completed
status for receipted orders.
This patch excludes orderlines with the completed status
from having their status rewritten as a result of the
change in basket status
Made the subroutines involved more efficient by removing an
unnecessary loop and by not fetching a large amount of
Signed-off-by: Kyle M Hall <firstname.lastname@example.org>
Patch pushed to master.
*** Bug 13467 has been marked as a duplicate of this bug. ***
This patch has been pushed to 3.20.x, will be in 3.20.6.
Pushed to 3.18.13, and released.
A note for later: Should we also include a database update to recalculate the status affected correctly? The initial SQL when the feature was introduced could give some ideas.