[Bug 13636] New: Search results item status incorrect for holds
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13636 Bug ID: 13636 Summary: Search results item status incorrect for holds Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching Assignee: gmcharlt@gmail.com Reporter: kyle@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org 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. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13636 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff Patch complexity|--- |Small patch -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13636 --- Comment #1 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 35580 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=35580&action=edit Bug 13636 - 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 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13636 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #35580|0 |1 is obsolete| | --- Comment #2 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 35581 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=35581&action=edit Bug 13636 - 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 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13636 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13636 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #35581|0 |1 is obsolete| | --- Comment #3 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 35608 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=35608&action=edit [SIGNED-OFF] Bug 13636 - 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> -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13636 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|gmcharlt@gmail.com |kyle@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13636 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13636 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #35608|0 |1 is obsolete| | --- Comment #4 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 35730 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=35730&action=edit [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. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13636 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to Master CC| |tomascohen@gmail.com --- Comment #5 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Patch pushed to master. Thanks Kyle! -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13636 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris@bigballofwax.co.nz Status|Pushed to Master |Pushed to Stable --- Comment #6 from Chris Cormack <chris@bigballofwax.co.nz> --- Pushed to 3.18.x will be in 3.18.4 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13636 Mason James <mtj@kohaaloha.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |rel_3_16_candidate CC| |mtj@kohaaloha.com --- Comment #7 from Mason James <mtj@kohaaloha.com> --- Possible selection for 3.16.x -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13636 Mason James <mtj@kohaaloha.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rel_3_16_candidate | --- Comment #8 from Mason James <mtj@kohaaloha.com> --- Pushed to 3.16.x, will be in 3.16.10 -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org