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

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This commit is contained in:
Jonathan Druart 2020-03-23 13:09:07 +01:00 committed by Martin Renvoize
parent 243a5395de
commit 757ca57bfd
Signed by: martin.renvoize
GPG key ID: 422B469130441A0F

View file

@ -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;
}