[Bug 33886] New: Flatpickr calendar - year controls for date of birth on memberentry.pl are not intuitive
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 Bug ID: 33886 Summary: Flatpickr calendar - year controls for date of birth on memberentry.pl are not intuitive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs@lists.koha-community.org Reporter: sally.healey@cheshiresharedservices.gov.uk QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle.m.hall@gmail.com I appreciate a lot of work has gone into swapping from the now-obsolete datepicker to flatpickr. However, when entering a date of birth on the joining form (memberentry.pl), on both the staff intranet and the public OPAC, flatpickr is not intuitive for users. For the staff, having a form cause frustrations when you're welcoming new patrons is not ideal - but at least we can train the staff on flatpickr's quirks. For new patrons trying to join on the OPAC, it's impossible to explain how to use it to them. We are concerned that patrons may choose not to join because of difficulty with the date of birth field. Full explanation: Koha previously used datepicker. It was possible to enter dates using just the keyboard (typing in), or just the mouse (using the datepicker calendar). With flatpickr, you can use the keyboard (typing in) - but if you attempt to use flatpickr as mouse-only, it's extremely long-winded. Flatpickr appears to be designed for mouse+keyboard together, which is unusual - and unexpected for the end user - in a calendar. With datepicker, the mouse workflow was: - Click to open datepicker. Then work from left to right, top to bottom: - Use the dropdown menu to select month. - Use the dropdown menu to select year. - Click on the date to select the date. These steps were all handled by the mouse alone. Using flatpickr, the mouse workflow is: - Click to open flatpickr Note that you cannot work from left to right. This is because flatpickr initialises with today's date. If you have a patron who is born in October but the current month is June, then October doesn't show in the month dropdown (as it's a date in the future). This means you have to start with the year, which is counterintuitive, as it's working right to left. - There is a box to type the year into - meaning that it's not mouse-only. Many average computer users might not even realise that this box can be typed into. Depending on how you use a mouse/keyboard (particularly Tenkey users), typing in can mean lifting your hand from the mouse to use the keyboard and going back again. - The year controls do not display until mouseover, so it's not immediately apparent to all users how the year can be manipulated - especially as this is juxtaposed with the permanently visible month dropdown controls. - When hovering over the year, the arrow controls then appear - and if you're expecting mouse-only input, you may believe you need to use these, rather than typing the year. - The arrow controls only increment +/- 1 year. It's not possible to click and hold to jump +/- 10 years, for example. If you try to use flatpickr as mouse-only and your patron was born in the 1950s, you'll be clicking for a very long time. So the mouse-only workflow ends up being: - Click to open flatpickr - Have to remember to work from right to left - Hover over the year so the arrow controls show - Click 70 times to get back to 1953 - Go right to left to the month drop down to select the month - Then select the date If you choose to type in the year instead, it feels as if it's defeating the object of having a calendar, as you've already typed in 4 digits out of an 8 digit date. Frequent requests have been made to the developer on GitHub for a change to this workflow, but the developer prefers their existing implementation - so a change would need to be a plugin. To alleviate the friction with the year selection, is there a plugin that can be adopted/written/implemented? It doesn't have to be a dropdown plugin; in other calendars, there are different mouse-only methods of handling years, for example: https://element.eleme.cn/#/en-US/component/date-picker (this style is used in Windows). There's some discussion of this on StackOverflow: https://stackoverflow.com/questions/51425067/flatpickr-adding-dropdown-to-ch... - including some solutions. And there's a recent (May 2023) dropdown plugin linked from that page: https://gist.github.com/ZachSaucier/ec6f58e49082c27eaae240786bc82997 Please could a plugin be considered? Or a different method of handling year inputs, at least where date of birth is a flatpickr field? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 Sally <sally.healey@cheshiresharedservices.gov.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=28376 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 Daniel Jones <daniel.jones@cheshiresharedservices.gov.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.jones@cheshireshared | |services.gov.uk -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Maybe being able to type the year/date again is a little help here: Bug 33821 - OPAC flatpickr no longer allows for direct input of date -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #2 from Sally <sally.healey@cheshiresharedservices.gov.uk> --- Is it possible to launch flatpickr with a different date, rather than today? It wouldn't resolve the problem, but it would mitigate it slightly. If it initiated say, 20 years ago, rather than with the current date, at least every user can select their date and month - and then they can try to work out the year controls after. At the moment, if you try to join on the OPAC (or via the staff client) and your birthday is the 20th of November, you have to change the year first - whilst those born on the 4th of April don't. It's not intuitive. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 Fiona Borthwick <fiona.borthwick@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fiona.borthwick@ptfs-europe | |.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com, oleonard@myacpl.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |23003 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23003 [Bug 23003] Accessibility improvements -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=33703 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |martin.renvoize@openfifth.c |ity.org |o.uk -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #3 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 193933 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=193933&action=edit Bug 33886: Add DateInputStyle system preference for split date inputs Adds a new 'DateInputStyle' system preference (single|split) in the I18N/L10N section that controls how date input fields are presented across the entire interface. In 'split' mode, date fields are replaced by three auto-advancing text inputs (Day, Month, Year — ordered by the dateformat preference) plus an optional calendar button that opens the flatpickr picker on demand. This gives users the best of all worlds: accessible separate fields for those who prefer them, plus the familiar calendar picker for those who want it. The implementation lives entirely in calendar.inc (both staff and OPAC), so no per-template HTML changes are needed. The apply_flatpickr() function routes eligible fields to apply_split_date_widget() when split mode is active; time, datetime, and booking period fields are excluded. A validateSplitDateInputs() utility function handles form validation for any split widget on the page. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #4 from David Cook <dcook@prosentient.com.au> --- I think that I might understand what's going on. Maybe we could get some screenshots? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #5 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 193970 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=193970&action=edit Bug 33886: Replace DateInputStyle syspref with data-flatpickr-split attribute Remove the DateInputStyle system preference and instead control split date input mode via a data-flatpickr-split="true" attribute on individual fields. This allows per-field control rather than a global setting. Apply split inputs to fields where they are most appropriate: - dateofbirth (memorable date, typically far in the past) - dateexpiry (far-future date, analogous to card expiry) The atomicupdate is updated to delete the preference on upgrade. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #6 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 193971 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=193971&action=edit Screenshot of new inputs -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #7 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Just had a quick look, but do we really need to delete a preference that doesn't exist yet? It looks on first glance, like that database update could be obsolete. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #8 from Owen Leonard <oleonard@myacpl.org> --- My question is whether we might accomplish the same thing using a single input with some JS masking which would behave like three inputs but allow pasting? See Bug 39882 That might making it so that a global solution (rather than a pref) was acceptable in every situation -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #9 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- So the input masking already works exactly that way for the date input... but it's not clear you can actually input into the box in the first place and that's confusing users.. also, it's apparently pretty standard for DOB fields to be the three box trick. As for squashing the two patches Katrin.. yes that was my intention but I wanted feedback regarding pref driven and affecting all inputs vs dev chooses which inputs are one or the other at field creation time -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #10 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- This needs to have a test plan. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #11 from David Nind <david@davidnind.com> --- I didn't ask about date pickers at the accessibility meeting on (my) Thursday, as someone else beat me to it! A quick summary: - Use the form input types for date, time, and datetime-local - these are now widely supported and highly recommended, see https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/d... - This is in preference to JavaScript-based date pickers, which can be very problematic for accessibility - Some reasons for this: - adapts to different browsers nicely, as well as on phones - one less external library to worry about updating - If you are going to use a JavaScript date picker, then "normal" accessibility testing things should be thoroughly tested - This includes (but not limited to): - use the keyboard to successfully navigate the date picker - make it clear in your styling (and aria (?) roles) that elements are interactive ("visual affordance") and that they can be "clicked" or selected - ***The overwhelming comment was that you should be able to type in the date rather than scroll*** (particularly the year selecter, such as for year of birth) Is there any reason we don't use the standard form input date types in Koha? (Apart from it being a big change!) So the form should capture (or show) the date, or date time, and then save or return it from the database - then Koha should do whatever is required with it. I tried to navigate the existing date picker using just a keyboard, and failed! So I think that is a failure from an accessibility point of view as a starting point. (And I wonder why this hasn't (maybe it has) been brought to our attention already!) Summary: - I fully support being able to enter dates manually, instead of having to use a date picker - We should look into using the form input types for dates and time: date, datetime-local, and time https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/d... - If we do continue to use a JavaScript-based date picker it needs to "fully accessible", then as a bare minimum it should be navigable by using the keyboard - our current date picker fails on that score (or maybe it is just me - particularly navigating to the month and year, I couldn't work out how to do this without using the mouse) PS: I remember the trials and tribulations when we changed last time, although I wasn't directly involved in the testing! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #12 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Date of birth and expiry date fields on the patron form now render as three separate numeric text inputs (Day, Month, Year) ordered and separated according to the dateformat preference, plus a calendar button and clear button. All other date fields retain the standard flatpickr widget. Fields affected: dateofbirth (staff + OPAC), dateexpiry (staff only). Setup Apply patches, run yarn css:build inside KTD. Have an existing patron with a DOB set. Enable OPAC self-registration. Staff patron form Widget appearance - Date of birth and expiry date show three text inputs (Day/Month/Year) with labels, separators, a calendar icon button, and a clear (×) button - Registration date, password expiration date, and restriction expiry retain the standard flatpickr — confirm no split widget appears on these Part ordering by dateformat ┌────────────┬────────────────────┬───────────┐ │ dateformat │ Order │ Separator │ ├────────────┼────────────────────┼───────────┤ │ metric │ Day / Month / Year │ / │ ├────────────┼────────────────────┼───────────┤ │ us │ Month / Day / Year │ / │ ├────────────┼────────────────────┼───────────┤ │ dmydot │ Day / Month / Year │ . │ ├────────────┼────────────────────┼───────────┤ │ iso / sql │ Year / Month / Day │ - │ └────────────┴────────────────────┴───────────┘ Typing behaviour - Entering 2 digits in Day or Month auto-advances focus to the next input; Backspace does not auto-advance - Completing all three parts updates the hidden ISO input (YYYY-MM-DD) - Clearing any part clears the hidden input Calendar button - Opens the flatpickr picker; selecting a date populates all three split inputs and the hidden ISO input Clear button - Empties all three split inputs and the hidden ISO input Edit mode — existing patron's DOB and expiry pre-populate correctly in the split inputs Duplicate mode — DOB and expiry split inputs are empty (not copied) Validation - Required DOB with all inputs empty → alert, focus on first split input - Any partial entry (some parts filled, not all) → alert about incomplete date - Invalid calendar date (e.g. 31/02/2024) → alert about invalid date - Valid complete date → form submits, correct date stored OPAC self-registration - Split widget renders for date of birth with correct ordering/separator - Typing, calendar, and clear behave the same as staff - Partial or invalid entry blocks form submission; valid entry saves correctly Accessibility - Each split input has a <label> with a matching for attribute - Separators have aria-hidden="true"; calendar and clear buttons have aria-label - autocomplete attributes set: bday-day, bday-month, bday-year - Tab order flows naturally through the three inputs and buttons Regression Verify standard flatpickr fields elsewhere (acquisitions dates, circulation due dates, report date ranges, datetime fields) are unaffected. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA CC| |blawlor@clamsnet.org --- Comment #13 from Brendan Lawlor <blawlor@clamsnet.org> --- Overall I liked how the split input works for entering dates. It's also nice that it can be controlled per field. I'm failing QA because when navigating the form with the keyboard, on a split input date, if you hit enter on the calendar icon to open the date picker, the focus stays on the calendar icon, and you can't navigate the date picker using using the arrow keys at all. That violates WCAG 2.4.3 Focus Order. Someone using keyboard navigation is able use the button that says 'Open calendar', but focus remains on the icon instead going into the calendar that they opened. They would have to try tabbing through the rest of the page to hopefully get to the date picker With the standard flatpickr inputs currently in Koha, focus is not handled properly, but you can at least navigate the calendar using the arrow keys and use enter to select a date. There are some more specific accessibility issues with flatpickr mentioned here: https://github.com/flatpickr/flatpickr/issues/3065 (In reply to David from comment #11)
We should look into using the form input types for dates and time: date, datetime-local, and time https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/d...
I agree with this idea, but understand it would be a big change. The input type date allows for for similar split style input for dates, but with full keyboard support. You can use up and down arrows on each date part and focus is properly handled in the calendar date picker too. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #14 from Brendan Lawlor <blawlor@clamsnet.org> --- (In reply to David Nind from comment #11)
I tried to navigate the existing date picker using just a keyboard, and failed! So I think that is a failure from an accessibility point of view as a starting point. (And I wonder why this hasn't (maybe it has) been brought to our attention already!)
Keyboard navigation support for the current flatpickr in Koha is a big fail. Focus doesn't work properly. You have to somehow figure out that you enter the calendar with the up or down arrow. Then you can only navigate day by day or week by week with the arrow keys. You can't tab to the month or year controls. If you manage to tab to the Yesterday Today and Tomorrow buttons, they don't even work and you have to hit esc to exit. If you enter the an input with an existing date, and without opening the calendar, if you just want to edit a month, date or year, when you hit backspace it removes the whole date. It's full of pitfalls. The standard input with type date is really intuitive for keyboard users. The only thing the flatpickr seems to offer is the ability to paste a date. The standard date input. The standard date picker is not really compatible with pasting, unless you make a compromise and have a text input with a hidden date input. You could have a calendar icon next to the text input that calls the showPicker() function on the date input. Then you would have a little js to keep those fields in sync. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #15 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197508 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197508&action=edit Bug 33886: (QA follow-up) Use native date input for split mode Replace the custom split date widget (3 text inputs + flatpickr calendar button) with native <input type="date"> to fix WCAG 2.4.3 Focus Order violation. The custom widget failed keyboard accessibility: activating the calendar button via keyboard left focus on the button instead of moving it into the calendar, and flatpickr's calendar itself lacks proper keyboard navigation. Native date inputs provide built-in split date-part editing, keyboard-navigable calendar picker, and proper focus management with no custom JS required. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #16 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Another try as a follow-up.. I'm getting round to the stage of just dropping flatpickr entirely.. but for now I've just replaced the work here with a follow-up that removes it all and replaces it with native date input fields. Please test on Chrome, Firefox, Safari, Android, iPhone etc etc -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #17 from Brendan Lawlor <blawlor@clamsnet.org> --- (In reply to Martin Renvoize (ashimema) from comment #16)
Another try as a follow-up..
I'm getting round to the stage of just dropping flatpickr entirely.. but for now I've just replaced the work here with a follow-up that removes it all and replaces it with native date input fields.
Please test on Chrome, Firefox, Safari, Android, iPhone etc etc
Cool! I'm excited to test this! I believe using native html elements is the way to go whenever possible because they generally meet all the WCAG requirements by default. Thanks Martin! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #18 from Brendan Lawlor <blawlor@clamsnet.org> --- The native date input works really nice. One small accessibility issue I found is that when focus is on the calendar icon, the enter key does not work as expected to open the date picker because of the class="noEnterSubmit" I looked into it and it doesn't seem to work to remove the noEnterSubmit class where you remove the flatpicker class because of a line on members.js. It could be fixed like this on prog/js/members.js line 288: - $("fieldset.rows input, fieldset.rows select").addClass("noEnterSubmit"); + $("fieldset.rows input:not([type=date]), fieldset.rows select").addClass("noEnterSubmit"); The other thing I found is that this also updates the Expiry date input to use the native html, but leaves the registration date as a flatpicker. Was that intentional? I think for consistency all three date inputs on the member entry page should work the same way. Overall I like the move to using the native html date input, but the implementation is a little weird that it's still a flatpicker input in the template and it's just updated with js. I wonder what's the rational for that? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #19 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- (In reply to Brendan Lawlor from comment #18)
The native date input works really nice.
One small accessibility issue I found is that when focus is on the calendar icon, the enter key does not work as expected to open the date picker because of the class="noEnterSubmit"
I looked into it and it doesn't seem to work to remove the noEnterSubmit class where you remove the flatpicker class because of a line on members.js.
It could be fixed like this on prog/js/members.js line 288: - $("fieldset.rows input, fieldset.rows select").addClass("noEnterSubmit");
+ $("fieldset.rows input:not([type=date]), fieldset.rows select").addClass("noEnterSubmit");
I noticed this but didn't dig very deep.. I found 'space' worked to trigger the picker. Sounds like you dug a bit deeper and like there's a nicer alternative.
The other thing I found is that this also updates the Expiry date input to use the native html, but leaves the registration date as a flatpicker. Was that intentional? I think for consistency all three date inputs on the member entry page should work the same way.
Overall I like the move to using the native html date input, but the implementation is a little weird that it's still a flatpicker input in the template and it's just updated with js. I wonder what's the rational for that?
I was really trying to just fix the core issue as reported by the sponsor initially.. but community kept pushing and making this grow in different places.. honestly. I'd like to just outright drop flatpickr entirely at this point but I think that should be on it's own bug as I can see it taking a while for community to all agree to it.. but basically I agree entirely with what your saying.. I'd like ALL, not just on this page, date/datetime etc pickers to be consistent. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 --- Comment #20 from Brendan Lawlor <blawlor@clamsnet.org> --- Could we just add data-flatpickr-split="true" to the dateenrolled input for now, so that at least all three date inputs on memberentry would be consistent? I'd also like to see the noEnterSubmit class removed from these inputs. Then I'd be 100% with sign off. I can totally understand a new bug for the larger issue of removing flatpicker entirely. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42403 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42403 [Bug 42403] We should drop Flatpickr in preference for native datepickers -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org