This is related to bug #15652. If you enable AllowHoldDateInFuture (and its OPAC variant), you get an additional "Hold starts on date". It is possible to select the current date from the datepicker in the OPAC. If no date is selected, the default is the current date. However, it is not clear to the patron that the current date is selected by default, as the field is empty if no date has been selected from the datepicker. This caused confusion among some of our patrons. Therefore we use a custom patch to have the current date shown in the field "Hold starts on date". What Marcel de Rooy wrote in the related bug, also applies here: "Although it does not really make any difference if you leave the startdate empty or put the current date in it, we concluded that it still makes a psychological difference."
Created attachment 161814 [details] [review] Bug 35977: Set holddatefrom default to today This patch sets the holddatefrom date to today by default on the opac.
Created attachment 161928 [details] [review] Bug 35977: Set holddatefrom default to today This patch sets the holddatefrom date to today by default on the opac. Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov>
Created attachment 162125 [details] [review] Bug 35977: Set holddatefrom default to today This patch sets the holddatefrom date to today by default on the opac. Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov> Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Created attachment 162126 [details] [review] Bug 35977: (follow-up) Perltidy whitespace fixes Signed-off-by: Owen Leonard <oleonard@myacpl.org>
(In reply to Mirjam Vantieghem from comment #0) > What Marcel de Rooy wrote in the related bug, also applies here: > "Although it does not really make any difference if you leave the startdate > empty or put the current date in it, we concluded that it still makes > a psychological difference." Nice quote :) 2016 already..
Still confused though about another "psychological effect". If the field is prefilled, the user might be inclined to go to the next field that he should still fill. If it is blank but required, (s)he is forced to pay a bit more attention? We do use the field to decide when to fetch a book from our shelves for the reading room. So a more accurate start date is of importance. Makes it a harder choice somehow.
We seem to have a regression here btw. Since it seems possible now to enter past dates in the start date field.
Hmm, I don't think the regression comes from here.. I just tested on master and you can select a past date there too without this patch... :(. I'll look into it however as that certainly is a regression somewhere.
Bug 36341 - "Hold starts on date" should be limited to future dates The above fixes the pre-existing lack of futuredate definitions.
Created attachment 164217 [details] [review] Bug 35977: (follow-up) Perltidy whitespace fixes Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
(In reply to Marcel de Rooy from comment #6) > Still confused though about another "psychological effect". If the field is > prefilled, the user might be inclined to go to the next field that he should > still fill. If it is blank but required, (s)he is forced to pay a bit more > attention? Passing QA, but highlighting for RM - I think in this case defaulting to today is more obvious for general purposes. IMHO, you can use a bit of jQuery to clear the field since you have a unique use case
Created attachment 164220 [details] [review] Bug 35977: Set holddatefrom default to today This patch sets the holddatefrom date to today by default on the opac. Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov> Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 164221 [details] [review] Bug 35977: (follow-up) Perltidy whitespace fixes Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This will also need rebased on 36341 - but it broke the date population when I tried
(In reply to Nick Clemens from comment #11) > (In reply to Marcel de Rooy from comment #6) > > Still confused though about another "psychological effect". If the field is > > prefilled, the user might be inclined to go to the next field that he should > > still fill. If it is blank but required, (s)he is forced to pay a bit more > > attention? > > Passing QA, but highlighting for RM - I think in this case defaulting to > today is more obvious for general purposes. > IMHO, you can use a bit of jQuery to clear the field since you have a unique > use case Hm. I think with OPACMandatoryHoldDates set to have the start date as mandatory. This is the standard behavior for required fields as it forces the user to make an active choice, otherwise the preference basically has no effect. A lot can be solved with JS, but I think we need consistent behavior as the default. And JS is not as reachable or easy to a lot of libraries as it is for some of us. Especially with the new date widget it can get tricky.
Created attachment 165535 [details] [review] Bug 35977: Set holddatefrom default to today This patch sets the holddatefrom date to today by default on the opac. Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov> Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 165536 [details] [review] Bug 35977: Nuke value if setting required
I am sorry, but this breaks the datepickers on the OPAC reserve page totally for me now :( The input shows: 2024-04-26T1 JS error: Uncaught ReferenceError: Date_from_syspref is not defined I was a little mean and set the DateFormat to the German DD.MM.YYYY.
... as I just accidentally pushed this - could we get a quick follow-up?
I'm on it.
Created attachment 165725 [details] [review] Bug 35977: (follow-up) Use KohaDate instead of raw This patch updates the value passed to the holdfrom input to use KohaDate formatting instead of Raw. The 'futureinclusive' logic now being triggered in the flatpickr instantiation expects the localised date format as apposed to the raw one. However, I can't get the flatpickr and input to pick up the passed date properly now :(.
I'm stuck.. I can't get the value to be properly picked up by flatpickr.
Created attachment 165910 [details] [review] Bug 35977: (follow-up) Cleaner working approach This patch removes the Date_from_syspref recently added and replaces it with the correct parseDate call as per bug 35559. We also clean up the code around setting the input value in the first place and use iso which is what the rest of flatpickr expects and now is handled correctly in futuredate pickers. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Thanks to Nick for helping me wrap my head around this and Emily for the clean code in bug 35559 which lead to the fix. This should be ready to go again now Katrin.
Follow-up will be pushed to main.
Pushed for 24.05! Well done everyone, thank you!
Depends on Bug 36341 that added function Date_from_syspref()
Pushed to 23.11.x for 23.11.06
Backported to 23.05.x for upcoming 23.05.12
This patch seems to resolve issues with an empty flatpickr on opac-reserve using a mobile phone (Android) on 22.11 too. Note that I have OPACMandatoryHoldDates but did not incorporate the change of the second patch.