http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13022
Owen Leonard <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion --- Comment #2 from Owen Leonard <[email protected]> --- 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. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
