http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13022 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff --- Comment #3 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Owen Leonard from comment #2)
This is an interesting bug... I had no idea this arbitrary limitation was in the code. Note the associated FIXME:
# A couple heuristics to limit how many times # we query the database for item transfer information, sacrificing # accuracy in some cases for speed; # # 1. don't query if item has one of the other statuses # 2. don't check transit status if the bib has # more than 20 items # # FIXME: to avoid having the query the database like this, and to make # the in transit status count as unavailable for search limiting, # should map transit status to record indexed in Zebra.
The problem with both the old way and the patched version of things is that something is happening which the user doesn't know anything about. You can pick an arbitrarily high number for MaxSearchResultsItemsPerRecordStatusCheck (that's a mouthful!) and rest assured that no inaccurate information will be displayed or you can set it to something else and take your chances.
How does the librarian administrator know what value of MaxSearchResultsItemsPerRecordStatusCheck is reasonable?
I'm interested in hearing why the solution proposed in the FIXME isn't the one which has been implemented.
If the Zebra solution is not a good one, I think a better solution to this might just be to add a note which tells the user to click through to the detail page for accurate status information.
I don't think that would be a satisfactory solution for many librarians. The zebra fix is also limited. This problem isn't just inherent in the transit status, but also the lost status ( and probably the not for loan status and who knows what else ). I think the most correct solution would be to remove the limit altogether, but in the interest of those libraries that would prefer speed over accuracy, I made the limit controllable via a system preference instead. -- You are receiving this mail because: You are watching all bug changes.