See also bug 37650. When we consider ConfirmFutureHolds to build the holds to pull list, we actually could say that these holds, probably only one or two days ahead, are current holds too. Currently, they are just completely ignored. But e.g. having a library depot further away require collecting those items earlier etc. At least the majority of calls look like they could use the lookahead days from ConfirmFutureHolds. Filed as enh, but very close to a bug.
Created attachment 171247 [details] [review] Bug 37651: Add ConfirmFutureHolds to item->current_holds Test plan: Add future item level hold for another branch. Check in. Confirm and transfer. Note that without this patch, there is no patron info for the column On hold for on transferstoreceive. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 171248 [details] [review] Bug 37651: Add ConfirmFutureHolds to biblio->current_holds Test plan: Easy way is to run the unit tests in the next patch. One call of biblio->current_holds is hidden in acqui/parcel.pl. The table column "Item holds / Total holds" should now make a difference for an order referring to an item having future holds. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 171249 [details] [review] Bug 37651: Unit tests Test plan: Run t/db_dependent/Holds.t (Without previous patches, it would fail.) Run t/db_dependent/Koha/Biblios.t
Created attachment 171250 [details] [review] Bug 37651: Unit tests Test plan: Run t/db_dependent/Holds.t (Without previous patches, it would fail.) Run t/db_dependent/Koha/Biblios.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 176654 [details] [review] Bug 37651: Add ConfirmFutureHolds to item->current_holds Test plan: Add future item level hold for another branch. Check in. Confirm and transfer. Note that without this patch, there is no patron info for the column On hold for on transferstoreceive. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 176655 [details] [review] Bug 37651: Add ConfirmFutureHolds to biblio->current_holds Test plan: Easy way is to run the unit tests in the next patch. One call of biblio->current_holds is hidden in acqui/parcel.pl. The table column "Item holds / Total holds" should now make a difference for an order referring to an item having future holds. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 176656 [details] [review] Bug 37651: Unit tests Test plan: Run t/db_dependent/Holds.t (Without previous patches, it would fail.) Run t/db_dependent/Koha/Biblios.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Rebased. Waiting since September..
Created attachment 176808 [details] [review] Bug 37651: Add ConfirmFutureHolds to item->current_holds Test plan: Add future item level hold for another branch. Check in. Confirm and transfer. Note that without this patch, there is no patron info for the column On hold for on transferstoreceive. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 176809 [details] [review] Bug 37651: Add ConfirmFutureHolds to biblio->current_holds Test plan: Easy way is to run the unit tests in the next patch. One call of biblio->current_holds is hidden in acqui/parcel.pl. The table column "Item holds / Total holds" should now make a difference for an order referring to an item having future holds. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 176810 [details] [review] Bug 37651: Unit tests Test plan: Run t/db_dependent/Holds.t (Without previous patches, it would fail.) Run t/db_dependent/Koha/Biblios.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 176811 [details] [review] Bug 37651: (QA follow-up) Add POD for Biblio method We were missing POD here. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This is a fun one.. current_holds is called in a fair number of places; thus, whilst this is a small and clear patch, it could have some wide-reaching effects. I'm signing off and will seek some QA opinions. My gut says it makes sense and is a step toward being able to deprecate C4::Reserves::CheckReserve.
(In reply to Martin Renvoize (ashimema) from comment #12) > Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Thx !
This feels wrong to me. The pref description: "Note that this number of days will be used too in calculating the default end date for the Holds to pull-report. But it does not interfere with issuing, renewing or transferring items." It seems that we need a filter_by method, and use it only where it needs this pref to be taken into account.
(In reply to Jonathan Druart from comment #15) > This feels wrong to me. > > The pref description: "Note that this number of days will be used too in > calculating the default end date for the Holds to pull-report. But it does > not interfere with issuing, renewing or transferring items." > > It seems that we need a filter_by method, and use it only where it needs > this pref to be taken into account. You are right. We should adjust the wording of that pref. Will add a follow-up. The filter_by comment is valid too. But I dont think that it should be done here. It is an improvement on its own. There are more methods that could be reworked into filter_by constructs. Like for instance: Koha/Biblio.pm current_checkouts Koha/Acquisition/Order.pm current_item_level_holds The point of this report is refine the existing two current_holds methods where the pref should be taken into account.
Created attachment 177372 [details] [review] Bug 37651: (QA follow-up) Rewording for pref ConfirmFutureHolds As requested by QA. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 178325 [details] [review] Bug 37651: Add ConfirmFutureHolds to item->current_holds Test plan: Add future item level hold for another branch. Check in. Confirm and transfer. Note that without this patch, there is no patron info for the column On hold for on transferstoreceive. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 178326 [details] [review] Bug 37651: Add ConfirmFutureHolds to biblio->current_holds Test plan: Easy way is to run the unit tests in the next patch. One call of biblio->current_holds is hidden in acqui/parcel.pl. The table column "Item holds / Total holds" should now make a difference for an order referring to an item having future holds. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 178327 [details] [review] Bug 37651: Unit tests Test plan: Run t/db_dependent/Holds.t (Without previous patches, it would fail.) Run t/db_dependent/Koha/Biblios.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 178328 [details] [review] Bug 37651: (QA follow-up) Add POD for Biblio method We were missing POD here. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 178329 [details] [review] Bug 37651: (QA follow-up) Rewording for pref ConfirmFutureHolds As requested by QA. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Rebased on tidied codebase
I am not convinced this is a desired behavior change for all libraries. When they decided to set the pref, it explicitly said "does not affect" several things Would you be open to a second setting within the pref: CircConfirmFutureHolds (at checkin, at renewal, at checkout - multi select?) starting no later then XX days
(In reply to Nick Clemens (kidclamp) from comment #24) > I am not convinced this is a desired behavior change for all libraries. When > they decided to set the pref, it explicitly said "does not affect" several > things > > Would you be open to a second setting within the pref: > > CircConfirmFutureHolds (at checkin, at renewal, at checkout - multi select?) > starting no later then XX days Hi Nick. Thanks for looking here ! The description "But it does not interfere with issuing, renewing or transferring items" is not the most lucky one. I might have added it myself long ago ;) Note also that we are talking about a feature that say over 90% of the libraries is not using. (HEA: 1040 AllowHoldDateinFuture 728 OPACAllowHoldDateInFuture ) Lets look at the processes mentioned. (When writing this patch, I reviewed all occurrences of current_holds btw.) Checkout AddIssue already calls MoveReserve and that does check ConfirmFutureHolds. So this is an "existing interference". The description was wrong. Renew CanBookBeRenewed calls current_holds. This is a "new interference". If a library allows future holds and wants to confirm them within a few days specified by ConfirmFutureHolds, currently this is ignored by CanBookBeRenewed. So the book is renewed although there is a hold for it on tomorrow. Not sure if we should write code for that? Probably most do not want to renew here. Transfer transferbook calls CheckReserves without lookahead days. So it does not block a transfer for a future hold (when not ignoring them altogether). Feels like a bug to me that could be solved on another report :) So there is currently no interference here. Discussion elsewhere? Checkin This is not relevant here. ConfirmFutureHolds already affects checkin (especially the popup). And this is already advertized accordingly. In conclusion, the new extra preference should only pertain to renewals. This would imo be a rather ugly exception. I would advise against it.
Moving back to SO queue. Any thoughts, Nick?
(In reply to Marcel de Rooy from comment #25) > The description "But it does not interfere with issuing, renewing or > transferring items" is not the most lucky one. I might have added it myself > long ago ;) > Note also that we are talking about a feature that say over 90% of the > libraries is not using. (HEA: 1040 AllowHoldDateinFuture 728 > OPACAllowHoldDateInFuture ) 10% is not an insignificant amount of libraries imo > Lets look at the processes mentioned. (When writing this patch, I reviewed > all occurrences of current_holds btw.) > > Checkout > AddIssue already calls MoveReserve and that does check ConfirmFutureHolds. > So this is an "existing interference". The description was wrong. 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 > Renew > CanBookBeRenewed calls current_holds. > This is a "new interference". If a library allows future holds and wants to > confirm them within a few days specified by ConfirmFutureHolds, currently > this is ignored by CanBookBeRenewed. So the book is renewed although there > is a hold for it on tomorrow. Not sure if we should write code for that? > Probably most do not want to renew here. 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 In my review, these are the effects: C4::Circulation CanBookBeRenewed (will now be no) C4/ILSDI/Services GetAvailability (will now be on hold) C4/Reserves AddReserve (will now not be set to waiting if there is a future hold) 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) I think below will just add the new holds to display without behaviour change: Koha/Acquisition/Order current_item_level_holds C4/SIP/ILS/Item new acqui/parcel.pl circ/transferstoreceive.pl opac/opac-reserve.pl reserve/request.pl I won't block this one, but can leave to the RM to decide - I would like to see tests added to CanBookBeRenewed and GetAvailability for QA
Created attachment 184438 [details] [review] Bug 37651: Add ConfirmFutureHolds to item->current_holds Test plan: Add future item level hold for another branch. Check in. Confirm and transfer. Note that without this patch, there is no patron info for the column On hold for on transferstoreceive. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 184439 [details] [review] Bug 37651: Add ConfirmFutureHolds to biblio->current_holds Test plan: Easy way is to run the unit tests in the next patch. One call of biblio->current_holds is hidden in acqui/parcel.pl. The table column "Item holds / Total holds" should now make a difference for an order referring to an item having future holds. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 184440 [details] [review] Bug 37651: Unit tests Test plan: Run t/db_dependent/Holds.t (Without previous patches, it would fail.) Run t/db_dependent/Koha/Biblios.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 184441 [details] [review] Bug 37651: (QA follow-up) Add POD for Biblio method We were missing POD here. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 184442 [details] [review] Bug 37651: (QA follow-up) Rewording for pref ConfirmFutureHolds As requested by QA. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> [EDIT] Added an exception for renewals. Moving to new report.
Created attachment 184443 [details] [review] Bug 37651: (follow-up) Still skip future holds for renewals We need a skip_future_holds flag in item->current_holds to make renewals act as they did before. There is no need to add it to biblio->current_holds. Test plan: Run t/db_dependent/Holds.t Interface test: Issue a book, place hold on tomorrow, set ConfirmFutureHolds to 2 days. Verify that renew is not blocked by this hold. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 184444 [details] [review] Bug 37651: (follow-up) Add GetAvailability test case for future hold Test plan: Run t/db_dependent/ILSDI_Services.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
(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.
Back into SO
Created attachment 185365 [details] [review] Bug 37651: Add ConfirmFutureHolds to item->current_holds Test plan: Add future item level hold for another branch. Check in. Confirm and transfer. Note that without this patch, there is no patron info for the column On hold for on transferstoreceive. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 185366 [details] [review] Bug 37651: Add ConfirmFutureHolds to biblio->current_holds Test plan: Easy way is to run the unit tests in the next patch. One call of biblio->current_holds is hidden in acqui/parcel.pl. The table column "Item holds / Total holds" should now make a difference for an order referring to an item having future holds. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 185367 [details] [review] Bug 37651: Unit tests Test plan: Run t/db_dependent/Holds.t (Without previous patches, it would fail.) Run t/db_dependent/Koha/Biblios.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 185368 [details] [review] Bug 37651: (QA follow-up) Add POD for Biblio method We were missing POD here. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 185369 [details] [review] Bug 37651: (QA follow-up) Rewording for pref ConfirmFutureHolds As requested by QA. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> [EDIT] Added an exception for renewals. Moving to new report. Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 185370 [details] [review] Bug 37651: (follow-up) Still skip future holds for renewals We need a skip_future_holds flag in item->current_holds to make renewals act as they did before. There is no need to add it to biblio->current_holds. Test plan: Run t/db_dependent/Holds.t Interface test: Issue a book, place hold on tomorrow, set ConfirmFutureHolds to 2 days. Verify that renew is not blocked by this hold. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 185371 [details] [review] Bug 37651: (follow-up) Add GetAvailability test case for future hold Test plan: Run t/db_dependent/ILSDI_Services.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
With this patchset applied /kohadevbox/koha/t/db_dependent/Reserves.t fails. Can you check on this?
Created attachment 185706 [details] [review] Bug 37651: (QA follow-up) Fix current_holds tests in Reserves.t Test plan: Run prove t/db_dependent/Reserves.t
(In reply to Lucas Gass (lukeg) from comment #44) > With this patchset applied /kohadevbox/koha/t/db_dependent/Reserves.t fails. > Can you check on this? Fixed.