I believe that in some conditions flatpickr creates invalid date entries that can be saved. To test: * Switch DateFormat to DD.MM.YYY * Go to the OPAC self registration form * Enter a date of 00.00.000 * It will show as: 30.12.00-1 in the input and can be saved We have seen something similar on bug 36466.
This breaks patron search and is nothing the library can fix themselves, it needs to be fixed within the database. Upping severity. It's also happening quite frequently.
Confirmed on main? I don't recreate.
It inserted "0001-01-01" and search is not broken.
(In reply to Jonathan Druart from comment #3) > It inserted "0001-01-01" and search is not broken. We end up with 0000-00-00 in these cases in dateofbirth. It happens in 22.11.16 reliably.
I have tried to find a way to replicate the issue, we are not sure what exactly the people registering are entering to cause the date, but it has happened at least 3 times now on different servers/instances. We are using the DD.MM.YYYY DateFormat - not sure if that could make a difference?
On 22.11.16, Using "00000000" make fp displays "30.12.00-1", save and get: Invalid value passed, borrowers.dateofbirth=00-1-12-30 expected type is date at /usr/share/perl5/Exception/Class/Base.pm line 88 So I guess it depends on the DBMS version.
Sounds like a duplicate of bug 27768.
Maybe bug 33703 is causing the behaviour difference between main and 22.11.16
Hm, more to investigate. We are currently updating to a newer Debian version which should also include a newer version of MariaDB. Maybe this will make a difference.
*** Bug 37142 has been marked as a duplicate of this bug. ***
This regularly kills patron search in our installation using self registration.
I have tried, without success, to recreate this on the OPAC self reg page in main.
Yes, I think we are missing something either in configuration or setup (DBMS version) that causes this :(
Lowering severity as we have trouble to replicate the problem. Please provide more information.
We've had at least 5 cases from different libraries on different servers running 22.11 so far. I think we need to keep trying to replicate as this is a real issue. Also other reports on mailing list/Mattermost about invalid dates.
I couldn't manage to enter an invalid date in a sandbox (24.06.00) either. But i was able to in our test-environment in 22.11. You can type in the date with zero's - in our case in the date-format DD.MM.YYYY. So it was 00.00.0000. It wasn't possible to do that in 24.06. I don't know if there's another way to enter the invalid date. But this way - typing in - was doable in 22.11. I have tested that in Firefox and Edge.