Bug 26429

Summary: If a waiting hold has expired the expiration date on the holds page shows for tomorrow
Product: Koha Reporter: Kelly McElligott <kelly>
Component: Hold requestsAssignee: Emmi Takkinen <emmi.takkinen>
Status: CLOSED FIXED QA Contact: Testopia <testopia>
Severity: major    
Priority: P5 - low CC: aleisha, cslone, didier.gautheron, emmi.takkinen, gmcharlt, hayleypelham, jonathan.druart, lucas, victor
Version: master   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25619
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25631
Change sponsored?: --- Patch complexity: Trivial patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
20.11.00, 20.05.06, 19.11.12
Bug Depends on: 25789    
Bug Blocks:    
Attachments: Bug 26429: Show correct expiration date at the request.pl
Bug 26429: Show correct expiration date at the request.pl
Bug 26429: Show correct expiration date at the request.pl

Description Kelly McElligott 2020-09-10 14:48:23 UTC
To recreate:
1. Have a waiting hold - the expiration date of 9/9/2020.
2. Reserve table shows 9/9, request.pl shows 9/9
3. Fast forward to 9/10
4. If library is not expiring holds, this hold expiration date will now show the expiration date of 9/11 on the request.pl page.
5. The reserve table still shows the 9/9 date.

It would appear that since the date picker (from the reserves.pl page) can not show dates in the past or even for the current date, it will show the next available date.

This is confusing! 


This bug seems very relevant to the bug I am filing:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21147
Comment 1 Chris Slone 2020-09-24 14:32:25 UTC
I can also confirm that we are seeing this and finding it confusing.
Comment 2 Emmi Takkinen 2020-09-25 11:11:37 UTC
My bad. I used "datepickerto" class (which is actually used when e.g filtering between dates) instead of adding "futuredate" class to this specific field in bug 25789.
Comment 3 Emmi Takkinen 2020-09-25 11:12:49 UTC
Created attachment 110748 [details] [review]
Bug 26429: Show correct expiration date at the request.pl

Bug 25789 changed holds tables expriration input class as "datepickerto".
This results to past expiration date to be displayed as tomorrows date.
Class "futuredate" should have been used instead.

To test:

1. Have waiting hold with expiration date in past (e.g 24.9)
2. Observe that waiting reserves table displays correct expiration date
3. At the request.pl page expiration date is however displayed as 26.9
=> Apply patch
4. Confirm that expiration date at the request.pl is now 24.
Comment 4 Owen Leonard 2020-10-06 14:17:36 UTC
Created attachment 111312 [details] [review]
Bug 26429: Show correct expiration date at the request.pl

Bug 25789 changed holds tables expriration input class as "datepickerto".
This results to past expiration date to be displayed as tomorrows date.
Class "futuredate" should have been used instead.

To test:

1. Have waiting hold with expiration date in past (e.g 24.9)
2. Observe that waiting reserves table displays correct expiration date
3. At the request.pl page expiration date is however displayed as 26.9
=> Apply patch
4. Confirm that expiration date at the request.pl is now 24.9

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Comment 5 Katrin Fischer 2020-10-13 13:48:41 UTC
Created attachment 111564 [details] [review]
Bug 26429: Show correct expiration date at the request.pl

Bug 25789 changed holds tables expriration input class as "datepickerto".
This results to past expiration date to be displayed as tomorrows date.
Class "futuredate" should have been used instead.

To test:

1. Have waiting hold with expiration date in past (e.g 24.9)
2. Observe that waiting reserves table displays correct expiration date
3. At the request.pl page expiration date is however displayed as 26.9
=> Apply patch
4. Confirm that expiration date at the request.pl is now 24.9

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 6 Jonathan Druart 2020-10-14 10:20:47 UTC
@RMaints, you will need this one for the next stable releases.
Comment 7 Jonathan Druart 2020-10-14 10:43:30 UTC
Emmy, I confirm that it fixes the problem, but I don't really understand something: I've tried to find out other wrong occurrences in our code and found one in serials/serials-search.tt. We have datepickerto without datepickerfrom.

However the date in the past is kept correctly there. Why that?
Comment 8 Jonathan Druart 2020-10-14 12:54:47 UTC
Pushed to master for 20.11, thanks to everybody involved!
Comment 9 Lucas Gass 2020-11-13 14:16:21 UTC
backported to 20.05.x for 20.05.06
Comment 10 Aleisha Amohia 2020-11-17 03:54:28 UTC
backported to 19.11.x for 19.11.12
Comment 11 Victor Grousset/tuxayo 2020-11-17 09:49:04 UTC
Missing dependencies for 19.05.x, can't backport.
Comment 12 Jonathan Druart 2021-04-13 09:03:33 UTC
*** Bug 28124 has been marked as a duplicate of this bug. ***