[Koha-bugs] [Bug 13022] Hardcoded limit causes records with more than 20 items to show inaccurate statuses
bugzilla-daemon at bugs.koha-community.org
bugzilla-daemon at bugs.koha-community.org
Thu Apr 16 17:43:46 CEST 2015
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13022
Kyle M Hall <kyle at bywatersolutions.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|In Discussion |Needs Signoff
--- Comment #3 from Kyle M Hall <kyle at 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.
More information about the Koha-bugs
mailing list