http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9788
--- Comment #41 from M. de Rooy <[email protected]> --- (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. _______________________________________________ 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/
