http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9788 --- Comment #41 from M. de Rooy <m.de.rooy@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.