https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37651
--- Comment #35 from Marcel de Rooy <[email protected]> --- (In reply to Nick Clemens (kidclamp) from comment #27) Thx for QA. > MoveReserve in this context is checking for future holds, but only to fill > the current patrons future holds - or cancel or remove waiting status from an > existing hold - it does not block the checkout in any way - and it looks like > this won't change after the patch. So the description seems right to me Well, we probably mean the same here. It sounds just different. Yes it does not block the checkout. But it does "interfere" in the sense that such a future hold from the same patron is filled. Same for reverting a waiting status or cancelling a future hold from someone else. So the description "does not interfere", which I would interpret as 'does not influence" is incorrect. Future holds are already respected/considered here. So they "interfere". > I don't know that this is true - a patron who has a back might be allowed to > renew as it is in their possession. I think future holds confirmation is > meant to capture a book that is returned - forcing others to return it > earlier is more akin to what bookings and recalls do. This is a significant > change in behavior I think, and should, at least, be added as a test case for > CanBookBeRenewed This is not a matter of forcing to return a book earlier. But it is about renewing when there is a hold within the next few days. In general, library policies will not allow renewal when there are future reservations (not even restricted to what we call future holds). Currently, Koha does not follow that pattern. It only looks at "current holds" (until today). I could even imagine that Koha should not only check the period of lookahead days in the ConfirmFutureHolds pref but should look at the whole renewal period. (Or limit the renewal period.) But that is not within the scope of this report. I understand your request of tests. And do think now that we might better move this change on its own report by adding a skip_future_holds flag for current holds in renewals. We could then remove that or make it a preference on a new report (opened 40435). What do you think? > C4::Circulation CanBookBeRenewed (will now be no) See above. > C4/ILSDI/Services GetAvailability (will now be on hold) This is display and looks good to me overall. Renewal goes via CanBookBeRenewed. Added a small subtest for status of GetAvailability. > C4/Reserves AddReserve (will now not be set to waiting if there is a future > hold) This depends on ReservesNeedReturns (1: "Don't automatically", 0: Automatically). It should be set to 0 or null (just 7 branches on HEA versus 15000+ who have value 1) TOGETHER WITH using future holds obviously. And note that this change seems to be in line with general policies (this new hold should not jump to waiting if there is already one within a few days). > Koha/Item first_hold (could now return a future hold over a non-future hold, > this seems okay to me, but I am not sure of all contexts of first_hold) Git grepped it. Looked a circ/transferstoreceive.pl; that seems fine. Occurrences are obscured by using $first_hold = $holds->next. Seems to be ok. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://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/
