http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13022
Kyle M Hall <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff --- Comment #3 from Kyle M Hall <[email protected]> --- (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. _______________________________________________ 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/
