This is an issue because of the datepicker on the holds page in intranet - it doesn't allow you to select today's date, so it sets the date to tomorrow, if you then update another hold you have just extended the suspension - and it can keep happening. To recreate: 1 - Place a hold in your system 2 - Set that hold (or all holds) to expire today update reserves set suspend_until=CONCAT( CURDATE()," 00:00:00"); 3 - Run misc/cronjobs/holds/auto_unsuspend_holds.p 4 - Note the hold is sitll suspended 5 - Visit /cgi-bin/koha/reserve/request.pl for the book with the hold 6 - Note the suspend date is tomorrow (and cannot be set to today] 7 - Click update holds - the date in db is now set to tomorrow
Created attachment 76953 [details] [review] Bug 21075: AutoUnsuspendHolds should unsuspend holds <= today To recreate: 1 - Place a hold in your system 2 - Set that hold (or all holds) to expire today update reserves set suspend_until=CONCAT( CURDATE()," 00:00:00"); 3 - Run misc/cronjobs/holds/auto_unsuspend_holds.p 4 - Note the hold is sitll suspended 5 - Visit /cgi-bin/koha/reserve/request.pl for the book with the hold 6 - Note the suspend date is tomorrow (and cannot be set to today] 7 - Click update holds - the date in db is now set to tomorrow 8 - Reset to today 9 - Apply patch 10 - Run the cron again 11 - Visit the page and note hold is unsuspended
Created attachment 76954 [details] [review] Bug 21075: Unit tests prove -v t/db_dependent/Reserves/AutoUnsuspendReserves.t
Created attachment 76960 [details] [review] Bug 21075: Unit tests prove -v t/db_dependent/Reserves/AutoUnsuspendReserves.t Signed-off-by: Pierre-Luc Lapointe <pierreluc.lapointe@inLibro.com>
(In reply to Nick Clemens from comment #0) > This is an issue because of the datepicker on the holds page in intranet - > it doesn't allow you to select today's date, so it sets the date to > tomorrow Why do not we fix the UI instead?
(In reply to Jonathan Druart from comment #4) > (In reply to Nick Clemens from comment #0) > > This is an issue because of the datepicker on the holds page in intranet - > > it doesn't allow you to select today's date, so it sets the date to > > tomorrow > > Why do not we fix the UI instead? Because the script is wrong, and fixing it means the UI works right :-) The description in staff side when suspending holds: Specify date on which to resume (MM/DD/YYYY) : If we resume on that date, then we unsuspend before that date (today)
I think the patch is correct, but there is still a bug in the GUI. I think we should show the actual suspension date accurately somehow. This still fixes a bug, so passing.
Created attachment 77423 [details] [review] Bug 21075: AutoUnsuspendHolds should unsuspend holds <= today To recreate: 1 - Place a hold in your system 2 - Set that hold (or all holds) to expire today update reserves set suspend_until=CONCAT( CURDATE()," 00:00:00"); 3 - Run misc/cronjobs/holds/auto_unsuspend_holds.p 4 - Note the hold is sitll suspended 5 - Visit /cgi-bin/koha/reserve/request.pl for the book with the hold 6 - Note the suspend date is tomorrow (and cannot be set to today] 7 - Click update holds - the date in db is now set to tomorrow 8 - Reset to today 9 - Apply patch 10 - Run the cron again 11 - Visit the page and note hold is unsuspended Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 77424 [details] [review] Bug 21075: Unit tests prove -v t/db_dependent/Reserves/AutoUnsuspendReserves.t Signed-off-by: Pierre-Luc Lapointe <pierreluc.lapointe@inLibro.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Filed bug 21147 for the calendar oddness.
Awesome work all! Pushed to master for 18.11
Pushed to 18.05.x for 18.05.03
Pushed to 17.11.x for 17.11.10
*** Bug 8864 has been marked as a duplicate of this bug. ***