calendar.inc still contains a reference to a variable which was removed by Bug 30011. This creates an error when using Flatpickr in some contexts.
Created attachment 133218 [details] [review] Bug 30514: Error in date format check following datepicker removal This patch corrects the is_valid_date function in the OPAC and staff interface so that it work correctly with Flatpickr. To test, apply the patch and clear your browser cache if necessary. - In the staff client, locate a bibliographic record and edit its items. - Test that the "Date acquired" date picker works correctly and that there are no errors in the browser console. - Test other date input fields to check that they still work, e.g. specify due date during checkout; Catalog statistics wizard; Patron entry/modification, etc. - Perform similar tests in the OPAC: Hold suspension; Update your personal details.
*** Bug 30561 has been marked as a duplicate of this bug. ***
Created attachment 133428 [details] [review] Bug 30514: Error in date format check following datepicker removal This patch corrects the is_valid_date function in the OPAC and staff interface so that it work correctly with Flatpickr. To test, apply the patch and clear your browser cache if necessary. - In the staff client, locate a bibliographic record and edit its items. - Test that the "Date acquired" date picker works correctly and that there are no errors in the browser console. - Test other date input fields to check that they still work, e.g. specify due date during checkout; Catalog statistics wizard; Patron entry/modification, etc. - Perform similar tests in the OPAC: Hold suspension; Update your personal details. Signed-off-by: David Cook <dcook@prosentient.com.au>
With different date formats, things don't appear quite right: * Changed Dateformat DD.MM.YYYY * Edit any patron * Set or edit date of birth * Verify the date is shown with / still, instead of selected dateformat
In my testing today I found that it works but only after "restart_all." I don't know why this would be. Individually restarting plack, memcached, or apache doesn't help. Other system preferences, like IntranetUserCSS, are applied immediately without restart.
What Katrin describes is not related to this bug report. It's very weird and I have no idea where it's coming from. I think there is still something wrong with this patch however. The is_valid_date does not work as we are expecting. We used to have an alert if the date was wrong. The following change will restore the historical behaviour: diff --git a/koha-tmpl/intranet-tmpl/prog/js/calendar.js b/koha-tmpl/intranet-tmpl/prog/js/calendar.js index 81561cc42d2..8ea4fbadfe6 100644 --- a/koha-tmpl/intranet-tmpl/prog/js/calendar.js +++ b/koha-tmpl/intranet-tmpl/prog/js/calendar.js @@ -22,12 +22,7 @@ function is_valid_date(date) { if (date.search(/^\d{2}\.\d{2}\.\d{4}($|\s)/) == -1) return 0; dateformat = 'd.m.Y'; } - try { - flatpickr.parseDate(date, dateformat); - } catch (e) { - return 0; - } - return 1; + return flatpickr.parseDate(date, dateformat) ? 1 : 0; } function get_dateformat_str(dateformat) {
(In reply to Jonathan Druart from comment #6) > What Katrin describes is not related to this bug report. It's very weird and > I have no idea where it's coming from. Hum, mornings... There is a bad space there: var dateformat_pref = "[% Koha.Preference('dateformat ') | html %]"; Not coming from this patch but bug 26261 (needs to be fixed separately).
I think that within the scope of this bug report the patch should not be considered Failed QA. I've posted Bug 30673 - Improve is_valid_date function for validating date strings - to address the issues raised in comment 4, comment 6, and comment 7. But none of those issues are related to the changes made by this patch.
Retesting this
Testing this again I noticed this in the console with the patch applied: Source map error: Error: request failed with status 404 Resource URL: http://localhost:8081/intranet-tmpl/lib/flatpickr/shortcut-buttons-flatpickr.min_21.1200048.js Source Map URL: shortcut-buttons-flatpickr.min.js.map separate bug?
(In reply to Owen Leonard from comment #5) > In my testing today I found that it works but only after "restart_all." I > don't know why this would be. Individually restarting plack, memcached, or > apache doesn't help. Other system preferences, like IntranetUserCSS, are > applied immediately without restart. I am seeing the same behavior, after a restart_all it's ok. I filed: Bug 30706 - DateFormat change only takes effect after a restart of services
Created attachment 134683 [details] [review] Bug 30514: Error in date format check following datepicker removal This patch corrects the is_valid_date function in the OPAC and staff interface so that it work correctly with Flatpickr. To test, apply the patch and clear your browser cache if necessary. - In the staff client, locate a bibliographic record and edit its items. - Test that the "Date acquired" date picker works correctly and that there are no errors in the browser console. - Test other date input fields to check that they still work, e.g. specify due date during checkout; Catalog statistics wizard; Patron entry/modification, etc. - Perform similar tests in the OPAC: Hold suspension; Update your personal details. Signed-off-by: David Cook <dcook@prosentient.com.au> Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Pushed to master for 22.05, thanks to everybody involved [U+1F984]