Bug 13636 - Search results item status incorrect for holds
Summary: Search results item status incorrect for holds
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low major (vote)
Assignee: Kyle M Hall
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-28 13:31 UTC by Kyle M Hall
Modified: 2015-12-03 22:03 UTC (History)
3 users (show)

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


Attachments
Bug 13636 - Search results item status incorrect for holds (3.60 KB, patch)
2015-01-28 13:35 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 13636 - Search results item status incorrect for holds (3.68 KB, patch)
2015-01-28 13:38 UTC, Kyle M Hall
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 13636 - Search results item status incorrect for holds (3.80 KB, patch)
2015-01-29 13:59 UTC, Kyle M Hall
Details | Diff | Splinter Review
[PASSED QA] Bug 13636 - Staff search results item status incorrect for holds (3.92 KB, patch)
2015-02-08 19:06 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2015-01-28 13:31:25 UTC
Imagine this scenario: we have one record with four items. Two of those items are checked out, one of those items is a waiting hold, and one of those items is available. We would expect to see this on the search results page. Instead, we will see both non-checked out items as unavailable due to waiting holds.

This is due to a semantic issue GetReserveStatus. C4::Search::searchResults uses GetReserveStatus to get the reserve status of each item, but unlike all other calls to the sub, this one passes in not only itemnumber, but biblionumber.

When no reserve is found for the available item, the subroutine uses the biblionumber to grab what is essentially an arbitrary reserve to use for the status. This makes no sense and this functionality should be entirely removed from the subroutine so regressions like this will be prevented in the future.
Comment 1 Kyle M Hall 2015-01-28 13:35:15 UTC Comment hidden (obsolete)
Comment 2 Kyle M Hall 2015-01-28 13:38:46 UTC Comment hidden (obsolete)
Comment 3 Kyle M Hall 2015-01-29 13:59:53 UTC Comment hidden (obsolete)
Comment 4 Katrin Fischer 2015-02-08 19:06:48 UTC
Created attachment 35730 [details] [review]
[PASSED QA] Bug 13636 - Staff search results item status incorrect for holds

Imagine this scenario: we have one record with four items. Two of those
items are checked out, one of those items is a waiting hold, and one of
those items is available. We would expect to see this on the search
results page. Instead, we will see both non-checked out items as
unavailable due to waiting holds.

This is due to a semantic issue GetReserveStatus.
C4::Search::searchResults uses GetReserveStatus to get the reserve
status of each item, but unlike all other calls to the sub, this one
passes in not only itemnumber, but biblionumber.

When no reserve is found for the available item, the subroutine uses the
biblionumber to grab what is essentially an arbitrary reserve to use for
the status. This makes no sense and this functionality should be
entirely removed from the subroutine so regressions like this will be
prevented in the future.

Test Plan:
1) Create one record with 4 items
   a) check two of the items out to patrons
   b) set one of the items as a waiting hold
   c) leave the fourth item as available
2) Run a search where this record will be in the results list
3) Note that the results list 2 items on loan, two unavailable
4) Apply this patch, reload the search results
5) Note that the results list 1 available, 2 on loan, 1 unavailable

Signed-off-by: John Andrews <jandrews@washoecounty.us>
Signed-off-by: Sheila Kearns <sheila.kearns@state.vt.us>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Note: This is for the staff search result list!

Works as expected.
Comment 5 Tomás Cohen Arazi 2015-02-12 18:30:43 UTC
Patch pushed to master.

Thanks Kyle!
Comment 6 Chris Cormack 2015-02-14 07:59:29 UTC
Pushed to 3.18.x will be in 3.18.4
Comment 7 Mason James 2015-02-26 05:02:07 UTC
Possible selection for 3.16.x
Comment 8 Mason James 2015-04-22 12:11:47 UTC
Pushed to 3.16.x, will be in 3.16.10