Bug 4430

Summary: Staff Results Display Showing Wrong Numbers
Product: Koha Reporter: Nicole C. Engard <nengard>
Component: SearchingAssignee: Galen Charlton <gmcharlt>
Status: CLOSED FIXED QA Contact: Bugs List <koha-bugs>
Severity: critical    
Priority: P5 - low CC: koha.sekjal, ohiocore
Version: Main   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2142
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: 2 copies showing as 1
5 copies show as 1 but 3 copies show as 3
all kinds of funniness

Description Chris Cormack 2010-05-21 01:27:05 UTC


---- Reported by nengard@gmail.com 2010-05-01 18:22:07 ----

Created an attachment
2 copies showing as 1

See the attached images.  When an item has multiple items available it says 2 items available - this is fine - but then it shows the call number and the item and a (1) ... shouldn't that be a (2) for the 2 items?  Sometimes it displays properly - but it seems to only show right when there are copy numbers in the records.



---- Additional Comments From nengard@gmail.com 2010-05-01 18:22:53 ----

Created an attachment
5 copies show as 1 but 3 copies show as 3





---- Additional Comments From nengard@gmail.com 2010-05-01 18:23:40 ----

XSLT Results display is off by the way - since it breaks the OPAC anyway.



---- Additional Comments From nengard@gmail.com 2010-05-03 12:01:10 ----

Created an attachment
all kinds of funniness

In the attached image you see that there are 4 available but it says (3) next to the call number. Then there are 2 on loan but it says (1).  And finally there are 4 unavailable for other reasons but there 2 reasons (in transit) and (on hold) and only (1) as the number.



---- Additional Comments From oleonard@myacpl.org 2010-05-03 13:50:59 ----

*** http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4431 has been marked as a duplicate of this bug. ***



---- Additional Comments From oleonard@myacpl.org 2010-05-07 18:13:03 ----

Reassigning this bug because it's not the result of a template issue AFAICT



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:27 UTC  ---

This bug was previously known as _bug_ 4430 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4430
This bug depended on bug(s) 2142.
Imported an attachment (id=2092)
Imported an attachment (id=2093)
Imported an attachment (id=2094)

Actual time not defined. Setting to 0.0
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
The original submitter of attachment 2092 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 2093 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 2094 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.

Comment 1 Joe Atzberger 2010-06-08 02:42:15 UTC
It might be enough to provide some visual indicator that the leaf details listed are not exhaustive of the summary node subtotal.  Something like "...", "more" or "and 2 more similar items".

It is definitely good to be able to avoid listing hundreds of items on the hitlist.
Comment 2 Ian Walls 2010-12-09 18:58:02 UTC
This can be solved by reintroducing the maxitemsinsearchresults system preference.  Items with the same branch, shelving location, callnumber and status are clustered together.

To reduce the number of entries, call numbers with copy or volume information should have that removed from itemcallnumber and put into copynumber or enumchron, respectively.
Comment 3 Owen Leonard 2014-07-10 17:25:20 UTC
As far as I can tell this is no longer an issue in master.