Bug 12631 - Inventory: fix "wrong place" and "item not scanned" statuses
Summary: Inventory: fix "wrong place" and "item not scanned" statuses
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Tools (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Matthias Meusburger
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-23 09:58 UTC by Matthias Meusburger
Modified: 2017-03-29 13:57 UTC (History)
11 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:


Attachments
Inventory: fix "wrong place" and "item not scanned" (3.60 KB, patch)
2014-07-23 10:03 UTC, Matthias Meusburger
Details | Diff | Splinter Review
Bug 12567: Make catalog statistics wizard publication year work for MARC21 (4.00 KB, patch)
2014-12-09 15:30 UTC, sandboxes@biblibre.com
Details | Diff | Splinter Review
BZ12631: Inventory: fix "wrong place" and "item not scanned" (3.67 KB, patch)
2015-02-12 06:09 UTC, Brendan Gallagher
Details | Diff | Splinter Review
[PASSED QA] Bug 12631: Inventory: fix "wrong place" and "item not scanned" (3.73 KB, patch)
2015-02-20 13:45 UTC, Kyle M Hall
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Meusburger 2014-07-23 09:58:39 UTC
What's wrong:
-------------

The current behavior in the inventory tool for item statuses is wrong on two points:

1) "item not scanned" status: when calling GetItemsForInventory, datelastseen should be used when "compare barcodes list to result" is checked.

Otherwise, when loading multiple barcodes files for the same inventory, many items will be marked as "item not scanned" when loading the last barcode file ("compare barcodes list to result" checked) even though they were scanned.

    
2) "wrong place" status: when searching for wrongly placed items, we should only check for the location (callnumbers, location and branch). To fix this, A new call to GetItemsForInventory has been made with location filters only.

Otherwise, any item with a different itemtype for instance will be marked as wrong place even if the location is correct.



Test plan:
----------

Providing a strict and precise test plan is quite hard, as it is strongly dependant of your database, but you can check as follow:

"item not scanned" status:

1) Split a barcode file in two.

2) Load the first barcode file without checking "compare barcodes list to result".

3) Load the second barcode file with "compare barcodes list to result" checked.

4) Check in the csv report that you have a lot of scanned items with the "item not scanned" status.

Then apply the patch, do the same, and check that the false "item not scanned" statuses are gone.


"wrong place" status:

1) Load a barcode file with barcode matching an item that has a correct location, but a different itemtype than what you're looking for.

2) Check in the results that this item will be marked as "change item status" and "wrong place".

Then apply the patch, do the same, and check that the only status for this item is "change item status", which is correct.



Remarks:
--------

I'm expecting concerns about the fact that GetItemsForInventory is now called twice instead of once, but keep in mind that inventory is a quite rare operation.

Also, I did not manage to find a more efficient way to fix this wrong behavior, suggestions welcome.
Comment 1 Matthias Meusburger 2014-07-23 10:03:47 UTC Comment hidden (obsolete)
Comment 2 Martin Renvoize 2014-09-04 13:21:16 UTC
Afraid we don't have anyone using this feature, so I'm not really in the best position to sign-off on it.

Maybe a mail to the dev list might stir some interest?
Comment 3 sandboxes@biblibre.com 2014-12-09 15:30:20 UTC
Patch tested with a sandbox, by sonia.bouis@univ-lyon3.fr <2>
Comment 4 sandboxes@biblibre.com 2014-12-09 15:30:38 UTC Comment hidden (obsolete)
Comment 5 Jonathan Druart 2014-12-10 09:35:54 UTC
Sonia, did you want to signoff this patch?
Comment 6 Koha Team Lyon 3 2014-12-11 12:39:06 UTC
no, I didn't sign off, it was the "sandbox bug"
Comment 7 Brendan Gallagher 2015-02-12 06:09:01 UTC Comment hidden (obsolete)
Comment 8 Brendan Gallagher 2015-02-12 06:11:12 UTC
(In reply to Brendan Gallagher from comment #7)
> Created attachment 35859 [details] [review] [review]
> BZ12631: Inventory: fix "wrong place" and "item not scanned"
> 
> "item not scanned": when calling GetItemsForInventory, datelastseen should
>  be used when "compare barcodes list to result" is checked.
> 
>  Otherwise, when loading multiple barcodes files for the same inventory, many
>  items will be marked as "item not scanned" when loading the last barcode
> file
>  ("compare barcodes list to result" checked) even though they were scanned.
> 
>  "wrong place": when searching for wrongly placed items, we should only check
>  for the location (callnumbers, location and branch). To fix this, A new call
>  to  GetItemsForInventory has been made with location filters only.
> 
>  Otherwise, any item with a different itemtype for instance will be marked as
>  wrong place even if the location is correct.
> 
>  Test plan:
> 
> "item not scanned" status:
> 
> 1) Split a barcode file in two.
> 2) Load the first barcode file without checking "compare barcodes list to
> result".
> 3) Load the second barcode file with "compare barcodes list to result"
> checked.
> 4) Check in the csv report that you have a lot of scanned items with the
> "item
> not scanned" status.
> 
> Then apply the patch, do the same, and check that the false "item not
> scanned"
> statuses are gone.
> 
> "wrong place" status:
> 
> 1) Load a barcode file with barcode matching an item that has a correct
> location, but a different itemtype than what you're looking for.
> 2) Check in the results that this item will be marked as "change item status"
> and "wrong place".
> 
> Then apply the patch, do the same, and check that the only status for this
> item is "change item status", which is correct.
> 
> Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>

I recently had a support ticket that dealt with inventory, so I easily had a few copies of barcodes.  I split into two and followed the test plan.  Excellent timing.
Comment 9 Kyle M Hall 2015-02-20 13:45:00 UTC
Created attachment 36082 [details] [review]
[PASSED QA] Bug 12631: Inventory: fix "wrong place" and "item not scanned"

"item not scanned": when calling GetItemsForInventory, datelastseen should
 be used when "compare barcodes list to result" is checked.

 Otherwise, when loading multiple barcodes files for the same inventory, many
 items will be marked as "item not scanned" when loading the last barcode file
 ("compare barcodes list to result" checked) even though they were scanned.

 "wrong place": when searching for wrongly placed items, we should only check
 for the location (callnumbers, location and branch). To fix this, A new call
 to  GetItemsForInventory has been made with location filters only.

 Otherwise, any item with a different itemtype for instance will be marked as
 wrong place even if the location is correct.

 Test plan:

"item not scanned" status:

1) Split a barcode file in two.
2) Load the first barcode file without checking "compare barcodes list to result".
3) Load the second barcode file with "compare barcodes list to result" checked.
4) Check in the csv report that you have a lot of scanned items with the "item
not scanned" status.

Then apply the patch, do the same, and check that the false "item not scanned"
statuses are gone.

"wrong place" status:

1) Load a barcode file with barcode matching an item that has a correct
location, but a different itemtype than what you're looking for.
2) Check in the results that this item will be marked as "change item status"
and "wrong place".

Then apply the patch, do the same, and check that the only status for this item is "change item status", which is correct.

Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 10 Tomás Cohen Arazi 2015-03-07 21:14:53 UTC
Patch pushed to master.

Thanks for the pastis Matthias!
Comment 11 Chris Cormack 2015-03-13 22:27:56 UTC
Pushed to 3.18.x will be in 3.18.5
Comment 12 Mason James 2015-03-27 01:32:41 UTC
Pushed to 3.16.x, will be in 3.16.9
Comment 13 Fridolin SOMERS 2015-04-22 07:08:23 UTC
Pushed to 3.14, will be in 3.14.15.