From d87351626d9bd9934da67e5963fc112aceb30f07 Mon Sep 17 00:00:00 2001 From: Jonathan Druart Date: Mon, 23 Mar 2020 13:09:07 +0100 Subject: [PATCH] Bug 23463: Fix selenium tests (highlight a bug in date management) There is something wrong, and a regression has been caught by those tests: If an invalid date is passed from the add item form, the app now crashes. Before: * if the date was completely invalid, the field was blanked silently * DateTime::Format::MySQL was used to convert dates, and it's not strict at all. For instance, what happened in the selenium tests for dateaccessionned: %Y-%m-%d was prefilled by the framework plugin, then the biblionumber was added, we ended with something like (eg for today) 2020-03-234242 (with biblionumber=4242). DateTime::Format::MySQL converts that to 2020-03-23 We must deal with invalid dates, but I do not think it is good to add it back to Koha::Item->store, we will prefer to raise the error to the end user, saying that something went wrong (and more specifically the dates). The (ugly) trick was in C4::Items::_mod_item_dates --- t/db_dependent/selenium/basic_workflow.t | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/t/db_dependent/selenium/basic_workflow.t b/t/db_dependent/selenium/basic_workflow.t index 62dcf0e470..a988bb8683 100644 --- a/t/db_dependent/selenium/basic_workflow.t +++ b/t/db_dependent/selenium/basic_workflow.t @@ -35,6 +35,7 @@ use Modern::Perl; use Time::HiRes qw(gettimeofday); +use POSIX qw(strftime); use C4::Context; use C4::Biblio qw( AddBiblio ); # We shouldn't use it @@ -197,6 +198,16 @@ SKIP: { # It's a varchar(10) $v = 't_value_x'; } + elsif ( + $id =~ m|^tag_952_subfield_w| # replacementpricedate + ) { + $v = strftime("%Y-%m-%d", localtime); + } + elsif ( + $id =~ m|^tag_952_subfield_d| # dateaccessioned + ) { + $v = ""; # The input has been prefilled with %Y-%m-%d already + } else { $v = 't_value_bib' . $biblionumber; } -- 2.20.1