Bug 29241

Summary: Flatpickr not displaying date in the past for futuredate
Product: Koha Reporter: Jonathan Druart <jonathan.druart>
Component: Staff interfaceAssignee: Jonathan Druart <jonathan.druart>
Status: CLOSED FIXED QA Contact: Testopia <testopia>
Severity: major    
Priority: P5 - low CC: david, gmcharlt, kyle, nugged
Version: unspecified   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: Small patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
21.11.00
Bug Depends on: 29240    
Bug Blocks: 29229, 29239, 29270, 29500    
Attachments: Bug 29241: Use allowInvalidPreload to allow date in the past
Bug 29241: Use allowInvalidPreload to allow date in the past
Bug 29241: Allow display of past date for .futuredate
Bug 29241: Allow display of past date for .futuredate
Bug 29241: Allow display of past date for .futuredate

Description Jonathan Druart 2021-10-14 08:25:09 UTC
For instance if a hold is expired (expirationdate in the past), the date input will be blanked.

To recreate:
Place a hold
Edit its expirationdate and set a date in the past (yesterday is fine)
Go to /reserve/request.pl?biblionumbers=42
Notice that the expirationdate is not displayed
Comment 1 Jonathan Druart 2021-10-14 08:27:14 UTC
Things to try (but bug 29240 needs to be fixed first):

* Use "enable" with expirationdate AND minDate # would be weird but worst to test
* Use "enable" with "expirationdate", {from: today_date} # Does it work without to?

https://flatpickr.js.org/examples/#supplying-dates-for-flatpickr
Comment 2 Jonathan Druart 2021-10-14 08:46:00 UTC
https://flatpickr.js.org/options/

allowInvalidPreload	Boolean	false	Allows the preloading of an invalid date. When disabled, the field will be cleared if the provided date is invalid
Comment 3 Jonathan Druart 2021-10-14 09:19:49 UTC
(In reply to Jonathan Druart from comment #2)
> https://flatpickr.js.org/options/
> 
> allowInvalidPreload	Boolean	false	Allows the preloading of an invalid date.
> When disabled, the field will be cleared if the provided date is invalid

It did not work when I was setting in from onReady, but it works when it's passed to the constructor.
Comment 4 Jonathan Druart 2021-10-14 09:36:23 UTC
Created attachment 126260 [details] [review]
Bug 29241: Use allowInvalidPreload to allow date in the past
Comment 5 Jonathan Druart 2021-10-14 09:36:49 UTC
This patch is the way to go.
Comment 6 Jonathan Druart 2021-10-14 11:07:27 UTC
Created attachment 126268 [details] [review]
Bug 29241: Use allowInvalidPreload to allow date in the past
Comment 7 Jonathan Druart 2021-10-19 08:06:25 UTC
Created attachment 126473 [details] [review]
Bug 29241: Allow display of past date for .futuredate

When a past date is set for a flatpickr instance with the .futuredate
class, only dates in the future are available AND the input is blanked.
It does not display the date in the past.

For instance if a hold is expired (expirationdate in the past), the date input will be blanked.

We can use the flatpickr's allowInvalidPreload option to allow date in the past to be displayed.

Test plan:
Place a hold
Edit its expirationdate and set a date in the past (yesterday is fine)
Go to /reserve/request.pl?biblionumbers=42
=> With the patch you see the date, and the widget let you chose anoter date,
in the future
=> Without this patch the expiration date is not displayed
Comment 8 David Nind 2021-10-21 17:42:32 UTC
Created attachment 126674 [details] [review]
Bug 29241: Allow display of past date for .futuredate

When a past date is set for a flatpickr instance with the .futuredate
class, only dates in the future are available AND the input is blanked.
It does not display the date in the past.

For instance if a hold is expired (expirationdate in the past), the date input will be blanked.

We can use the flatpickr's allowInvalidPreload option to allow date in the past to be displayed.

Test plan:
Place a hold
Edit its expirationdate and set a date in the past (yesterday is fine)
Go to /reserve/request.pl?biblionumbers=42
=> With the patch you see the date, and the widget let you chose anoter date,
in the future
=> Without this patch the expiration date is not displayed

Signed-off-by: David Nind <david@davidnind.com>
Comment 9 David Nind 2021-10-21 17:44:55 UTC
Testing notes (koha-testing-docker):

- date picker doesn't let you go back past the current date
- entering date manually works (and is retained) after patch is applied
Comment 10 Katrin Fischer 2021-10-23 23:10:06 UTC
Created attachment 126795 [details] [review]
Bug 29241: Allow display of past date for .futuredate

When a past date is set for a flatpickr instance with the .futuredate
class, only dates in the future are available AND the input is blanked.
It does not display the date in the past.

For instance if a hold is expired (expirationdate in the past), the date input will be blanked.

We can use the flatpickr's allowInvalidPreload option to allow date in the past to be displayed.

Test plan:
Place a hold
Edit its expirationdate and set a date in the past (yesterday is fine)
Go to /reserve/request.pl?biblionumbers=42
=> With the patch you see the date, and the widget let you chose anoter date,
in the future
=> Without this patch the expiration date is not displayed

Signed-off-by: David Nind <david@davidnind.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 11 Jonathan Druart 2021-10-25 13:59:01 UTC
Pushed to master for 21.11, thanks to everybody involved!
Comment 12 Jonathan Druart 2021-11-17 09:13:50 UTC
Unfortunately there is a problem with this patch. The futuredate class add both minDate and allowInvalidPreload. It fix the original problem describes here, but it also permits the user to enter invalid (in the past) dates.
Comment 13 Jonathan Druart 2021-11-17 10:21:37 UTC
(In reply to Jonathan Druart from comment #12)
> Unfortunately there is a problem with this patch. The futuredate class add
> both minDate and allowInvalidPreload. It fix the original problem describes
> here, but it also permits the user to enter invalid (in the past) dates.

See bug 29500.