Hi, After upgrade from 19.05 to 21.11.04 we got a problem with additem section. dateaccessioned area of additem doesn't seem correctly even we changed dateformat in systempreferences. I've removed the blank in the line var dateformat_pref = "[% Koha.Preference('dateformat') | html %]"; of calendar.inc
No data loss, that's not critical.
Created attachment 134781 [details] [review] Bug 30717: Format dates when editing items This is a result of bug 29369 and bug 27526. Bug 29369 removed the format of the dates, and bug 27526 assumed that it was the correct behaviour. Here we don't want to let the controller know which fields is a date, or we will have to access the subfield structure to know which subfields have the "date cataloguing plugin". This patch suggests to use the altFormat options from flatpickr that will "Show the user a readable date (as per altFormat), but return something totally different to the server." It's actually an option we want to use for all our dates, that will reduce a lot the overhead in our controllers. Test plan: Edit items (additem.pl and in batch) and confirm that the subfields using the dateaccessioned plugin are displayed according to the dateformat syspref. Make sure the date is stored correctly.
Created attachment 134797 [details] [review] Bug 30717: Format dates when editing items This is a result of bug 29369 and bug 27526. Bug 29369 removed the format of the dates, and bug 27526 assumed that it was the correct behaviour. Here we don't want to let the controller know which fields is a date, or we will have to access the subfield structure to know which subfields have the "date cataloguing plugin". This patch suggests to use the altFormat options from flatpickr that will "Show the user a readable date (as per altFormat), but return something totally different to the server." It's actually an option we want to use for all our dates, that will reduce a lot the overhead in our controllers. Test plan: Edit items (additem.pl and in batch) and confirm that the subfields using the dateaccessioned plugin are displayed according to the dateformat syspref. Make sure the date is stored correctly. Signed-off-by: David Nind <david@davidnind.com>
QAing
Created attachment 134947 [details] [review] Bug 30717: Format dates when editing items This is a result of bug 29369 and bug 27526. Bug 29369 removed the format of the dates, and bug 27526 assumed that it was the correct behaviour. Here we don't want to let the controller know which fields is a date, or we will have to access the subfield structure to know which subfields have the "date cataloguing plugin". This patch suggests to use the altFormat options from flatpickr that will "Show the user a readable date (as per altFormat), but return something totally different to the server." It's actually an option we want to use for all our dates, that will reduce a lot the overhead in our controllers. Test plan: Edit items (additem.pl and in batch) and confirm that the subfields using the dateaccessioned plugin are displayed according to the dateformat syspref. Make sure the date is stored correctly. Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 134948 [details] [review] Bug 30717: (QA follow-up) Move to module We will probably use this a bit more :) Let's put it in a module (with a trivial test). Test plan: Repeat item edit. Run t/DateUtils.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
QA tools gives a false negative: FAIL Koha/DateUtils.pm OK critic OK forbidden patterns OK git manipulation OK pod OK pod coverage SKIP spelling FAIL valid Subroutine flatpickr_date_form
Took me bit to figure out this qa tools warn, but this is the cause: perl -cw outputs: $VAR1 = 'Subroutine dt_from_string redefined at Koha/DateUtils.pm line 58. Subroutine output_pref redefined at Koha/DateUtils.pm line 269. Subroutine format_sqldatetime redefined at Koha/DateUtils.pm line 360. Subroutine flatpickr_date_format redefined at Koha/DateUtils.pm line 392. Koha/DateUtils.pm syntax OK '; The line Subroutine flatpickr_date_format redefined at Koha/DateUtils.pm line 392. goes thru the following regex: s/at .* line .*$// for @errors; And this regex is too generic. It already the last two letters at from the subroutine name! So it leaves: Subroutine flatpickr_date_form Which is no longer removed by the redefined regex.. s/^Subroutine .* redefined $// for @errors; Since redefined was already eaten.
Pushed to master for 22.05, thanks to everybody involved [U+1F984]
(In reply to Marcel de Rooy from comment #8) > Took me bit to figure out this qa tools warn, but this is the cause: > > perl -cw outputs: > $VAR1 = 'Subroutine dt_from_string redefined at Koha/DateUtils.pm line 58. > Subroutine output_pref redefined at Koha/DateUtils.pm line 269. > Subroutine format_sqldatetime redefined at Koha/DateUtils.pm line 360. > Subroutine flatpickr_date_format redefined at Koha/DateUtils.pm line 392. > Koha/DateUtils.pm syntax OK > '; > > The line Subroutine flatpickr_date_format redefined at Koha/DateUtils.pm > line 392. > goes thru the following regex: > s/at .* line .*$// for @errors; > And this regex is too generic. It already the last two letters at from the > subroutine name! > So it leaves: Subroutine flatpickr_date_form > Which is no longer removed by the redefined regex.. > s/^Subroutine .* redefined $// for @errors; > Since redefined was already eaten. Please report when you find bugs :) See https://gitlab.com/koha-community/qa-test-tools/-/issues/60
*** Bug 30659 has been marked as a duplicate of this bug. ***
Hi, I think this still needs backporting as it was reported against 21.11.04?
*** Bug 30361 has been marked as a duplicate of this bug. ***
pushed to 21.11.x for 21.11.07, thx!
Missing dependencies for 21.05.x, it shouldn't be affected, no backport.
Created attachment 137613 [details] [review] Bug 30717: Fix selenium tests Error while executing command: element not interactable: Element <input id="tag_952_subfield_w_810691" class="input_marceditor items.replacementpricedate noEnterSubmit flatpickr-input" name="items.replacementpricedate" type="hidden"> is not reachable by keyboard at /usr/share/perl5/Selenium/Remote/Driver.pm line 411.
No idea why this is not failing on 21.11 but git bisect led me to this bug.
Hum, we released 22.05 since this. Moving to its own bug report.
Selenium fix moved to bug 31139.