[Koha-bugs] [Bug 9788] Improvements for calling GetReservesFromItemnumber

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9788

--- Comment #41 from M. de Rooy <m.de.rooy at rijksmuseum.nl> ---
(In reply to M. Tompsett from comment #38)
> It seems that initially, the code was NOT called with a parameter passed for
> $alldates, and so the unless statement was always run. This is why it was
> moved up into the SQL, which is working. I suppose ordering by priority is
> considered part of the improvements too. And with the addition of the
> waitingdate into the SQL statement there is an improvement by including a
> confirmed future hold. Though, this is the part that makes me feel
> uncomfortable signing this off, even though it probably is okay.

Thanks for your comments.
Note that ordering by priority is a logical step. It actually solves the
following very small bug: If you have two item-level holds, the first is on
date A and the second is on date A-1, the second hold will have priority 1, but
catalogue/detail will show the first hold with priority 2 (because priority was
not used but just record order). This bug does not really hurt, it is just
wrong presentation. The priority sort fixes it. 

On the future hold: Could you further clarify? What makes you feel
uncomfortable about that part?
The idea behind this is: With ConfirmFutureHolds enabled, you confirmed a hold
for tomorrow. Currently, the routine checks <= NOW and thus ignores the fact
that the book is already waiting for borrower A (with highest priority) and
could say that it is still available (when no holds are returned) but it is no
longer. Makes that sense for you?

-- 
You are receiving this mail because:
You are watching all bug changes.