Summary: | Receiving orders create too much items | ||
---|---|---|---|
Product: | Koha | Reporter: | Julian Maurice <julian.maurice> |
Component: | Acquisitions | Assignee: | Julian Maurice <julian.maurice> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | critical | ||
Priority: | P5 - low | CC: | chris, elliott, katrin.fischer, kyle |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | Small patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Attachments: |
Bug 9126: Do not return from Check too early.
Bug 9126: Do not return from Check too early. [SIGNED-OFF] Bug 9126: Do not return from Check too early. [Passed QA] Bug 9126: Do not return from Check too early. |
Description
Julian Maurice
2012-11-21 16:38:02 UTC
Created attachment 13601 [details] [review] Bug 9126: Do not return from Check too early. If there is no errors, it should continue instead of returning true. + move a block of code at the end of Check function. This avoid detaching and re-attaching a HTML block if there are errors. Hi all, this is a critical bug in 3.10 - it would be awesome if someone could test and sign-off on this soon. Created attachment 13764 [details] [review] Bug 9126: Do not return from Check too early. If there is no errors, it should continue instead of returning true. + move a block of code at the end of Check function. This avoid detaching and re-attaching a HTML block if there are errors. Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> The following queries show us the issues: select count(*) from items; select * from aqorders_items where ordernumber=XX; I can reproduce this on master - changing version. I had managed to create 2 items during one of my first tests, but have not been able to reproduce it since. Hi Julian and Jonathan, I tested on master and on 3.8 - I can't reproduce it apart from that one time I thought it happened. What am I missing? AcqCreateItem = receive UniqueItemFields = barcode - I create a new basket, ordered quantity = 1 - I close the basket and start a new chipment - I receive the items, I tried - only filling out the barcode - only filling out the itemtype Hi Katrin, there's a thing I forgot to mention: it must be a partial receipt, so you can test by creating an order with quantity=2, and receive only one item. Hi Julian, I think that was the crucial bit of information - I had started testing with a partial receive and that was probably the one time I could reproduce the problem. If someone else could sign this off... I could QA it later... I'm unable to reproduce this bug on master. Perhaps a video of the bug in action would be helpful. Hello Kyle, I think the additional item is not created because of "unique key" on items.barcode. You may see in log file something like this: DBD::mysql::st execute failed: Duplicate entry '013' for key 'itembarcodeidx at /home/julian/koha/src/C4/Items.pm line 2105 DBD::mysql::st execute failed: Column 'itemnumber' cannot be null at /home/julian/koha/src/C4/Acquisition.pm line 1094. Try the following steps: - create order with quantity=2 and go to receipt page - fill the item form for the first item with a unique barcode and click 'add' - in the new item form change barcode so it is unique too but do not click on 'add' - click 'Save' - you should have 2 items created but parcel.pl indicates only 1 item received. Created attachment 14290 [details] [review] [SIGNED-OFF] Bug 9126: Do not return from Check too early. If there is no errors, it should continue instead of returning true. + move a block of code at the end of Check function. This avoid detaching and re-attaching a HTML block if there are errors. Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> The following queries show us the issues: select count(*) from items; select * from aqorders_items where ordernumber=XX; Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> To test: AcqCreateItem = receive UniqueItemFields = barcode 1) Create a new basket 2) Create a new order with quantity > 1 3) Close the basket and create a new invoice/shipment 4) Receive only 1 item. - Fill out the first item form with item type only. Click add. - Don't change second item form at all. - Click save. Before patch: 2 items are created on the record, both with the selected itemtype. After patch: Only 1 item is created, which is correct. Created attachment 14574 [details] [review] [Passed QA] Bug 9126: Do not return from Check too early. If there is no errors, it should continue instead of returning true. + move a block of code at the end of Check function. This avoid detaching and re-attaching a HTML block if there are errors. Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> The following queries show us the issues: select count(*) from items; select * from aqorders_items where ordernumber=XX; Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> To test: AcqCreateItem = receive UniqueItemFields = barcode 1) Create a new basket 2) Create a new order with quantity > 1 3) Close the basket and create a new invoice/shipment 4) Receive only 1 item. - Fill out the first item form with item type only. Click add. - Don't change second item form at all. - Click save. Before patch: 2 items are created on the record, both with the selected itemtype. After patch: Only 1 item is created, which is correct. Signed-off-by: Elliott Davis <elliott@bywatersolions.com> Seems to work as described by the test plan This patch has been pushed to master. Pushed to 3.8.x and 3.10.x Ok in 3.8.x, 3.10.x and master. |