Bug 5349 introduces the ability to transfer an order from a basket to another. After a transfer, if an order is received and the receipt is canceled, the order will be deleted.
Created attachment 24274 [details] [review] Bug 11549: Add regression test test plan: prove t/db_dependent/Acquisition/TransferOrder.t should fail before the patch and success after applying it.
Created attachment 24275 [details] [review] Bug 11549: FIX receive and cancel the receipt after a transfer. To reproduce the issue: - transfer an order from a basket to another. Note the previous ordernumber (X) and the new one (Y). - receive the order - cancel the receipt - verify the order has been deleted: select count(*) from aqorders where ordernumber=Y; select * from aqorders_transfers where ordernumber_from = X; The value for ordernumber_to is null. To test this patch: - apply this patch - transfer an order from a basket to another - receive the order - cancel the receipt - verify the order still exist in the basket where the transfer has been done.
Created attachment 24276 [details] [review] Bug 11549: Interpolate variables into SQL statements should not be allowed
I did several tests of transfers (from a basket, from the receipt page, after a double transfer). Every time, I received the document and cancelled the reception: the document returns as awaiting to be received. The discount of document to be received is OK. Everything is OK for me.
Patch tested with a sandbox, by Sonia BOUIS <sonia.bouis@univ-lyon3.fr>
Created attachment 24402 [details] [review] Bug 11549: Add regression test test plan: prove t/db_dependent/Acquisition/TransferOrder.t should fail before the patch and success after applying it. Signed-off-by: Sonia BOUIS <sonia.bouis@univ-lyon3.fr>
Created attachment 24403 [details] [review] Bug 11549: FIX receive and cancel the receipt after a transfer. To reproduce the issue: - transfer an order from a basket to another. Note the previous ordernumber (X) and the new one (Y). - receive the order - cancel the receipt - verify the order has been deleted: select count(*) from aqorders where ordernumber=Y; select * from aqorders_transfers where ordernumber_from = X; The value for ordernumber_to is null. To test this patch: - apply this patch - transfer an order from a basket to another - receive the order - cancel the receipt - verify the order still exist in the basket where the transfer has been done. Signed-off-by: Sonia BOUIS <sonia.bouis@univ-lyon3.fr>
Created attachment 24404 [details] [review] Bug 11549: Interpolate variables into SQL statements should not be allowed Signed-off-by: Sonia BOUIS <sonia.bouis@univ-lyon3.fr>
Created attachment 24487 [details] [review] Bug 11549: [follow-up] Make NewOrder calculate new parent_ordernumber If parent_ordernumber is not set in NewOrder parameter, it is automatically set to ordernumber. This patch only avoid code duplication.
Created attachment 24503 [details] [review] Bug 11549: [follow-up] Make NewOrder calculate new parent_ordernumber If parent_ordernumber is not set in NewOrder parameter, it is automatically set to ordernumber. This patch only avoid code duplication. Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> This solution is better!
Created attachment 24546 [details] [review] [PASSED QA] Bug 11549: Add regression test test plan: prove t/db_dependent/Acquisition/TransferOrder.t should fail before the patch and success after applying it. Signed-off-by: Sonia BOUIS <sonia.bouis@univ-lyon3.fr> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Testing notes on last patch.
Created attachment 24547 [details] [review] [PASSED QA] Bug 11549: FIX receive and cancel the receipt after a transfer. To reproduce the issue: - transfer an order from a basket to another. Note the previous ordernumber (X) and the new one (Y). - receive the order - cancel the receipt - verify the order has been deleted: select count(*) from aqorders where ordernumber=Y; select * from aqorders_transfers where ordernumber_from = X; The value for ordernumber_to is null. To test this patch: - apply this patch - transfer an order from a basket to another - receive the order - cancel the receipt - verify the order still exist in the basket where the transfer has been done. Signed-off-by: Sonia BOUIS <sonia.bouis@univ-lyon3.fr> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Created attachment 24548 [details] [review] [PASSED QA] Bug 11549: Interpolate variables into SQL statements should not be allowed Signed-off-by: Sonia BOUIS <sonia.bouis@univ-lyon3.fr> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Created attachment 24549 [details] [review] [PASSED QA] Bug 11549: [follow-up] Make NewOrder calculate new parent_ordernumber If parent_ordernumber is not set in NewOrder parameter, it is automatically set to ordernumber. This patch only avoid code duplication. Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> This solution is better! Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Passes all tests and QA script. Also all tests in t/db_dependent/Acquisitions/. Confirmed bug and that the patch fixes it.
Pushed to master. Thanks, Jonathan!
Patches pushed to 3.14.x, will be in 3.14.06