ModMember is not correctly interpreting dates if not passed in in ISO format. To see the issue: Go to Tools->Batch patron modification Enter some cardnumbers update any date field for the patrons Result is all null in that column The dates are being passed directly to ModMember without reformatting but there is an issue with DBIx::Class::ResultSet update where by dates are not processed/deflated http://search.cpan.org/dist/DBIx-Class/lib/DBIx/Class/ResultSet.pm#update I don't know whether the correct path here is to fix the call in Modmember, or to make modborrowers.pl pass the dates in a better format Marking as critical since data can be lost
I was able to view this in action in batch patron modification where a library entered a new date expiry using the date picker and the date was set to 0000 - 00-00 Example: Before modification in tool: TEMP0041 | 2015-08-11 | TEMP0042 | 2015-11-15 | TEMP0043 | 2015-11-15 | After modification: TEMP0041 | 0000-00-00 | TEMP0042 | 0000-00-00 | TEMP0043 | 0000-00-00 |
I was able to view this in action in batch patron modification where a library entered a new date expiry using the date picker and the date was set to 0000 - 00-00 Example with altered cardnumber: Before modification in tool: TEMP0041 | 2015-08-11 | TEMP0042 | 2015-11-15 | TEMP0043 | 2015-11-15 | After modification: TEMP0041 | 0000-00-00 | TEMP0042 | 0000-00-00 | TEMP0043 | 0000-00-00 |
Created attachment 45839 [details] [review] Bug 15332: Sent DateTime object to DBIx::Class, not formatted dates If formatted dates are sent to DBIx::Class on update/insert, the date will be set as 0000-00-00 (except if the format is yyyy-mm-dd). Test plan: Use the batch patron modification tools to update the dateenrolled or dateexpiry values for at least 1 patron. Without this patch, the modified value will be updated to 0000-00-00, with this patch, the correct value will be set.
This has certainly been introduced by bug 12633
I have quickly checked the other calls and they look good.
Created attachment 45870 [details] [review] Bug 15332: Sent DateTime object to DBIx::Class, not formatted dates If formatted dates are sent to DBIx::Class on update/insert, the date will be set as 0000-00-00 (except if the format is yyyy-mm-dd). Test plan: Use the batch patron modification tools to update the dateenrolled or dateexpiry values for at least 1 patron. Without this patch, the modified value will be updated to 0000-00-00, with this patch, the correct value will be set. Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 45980 [details] [review] Bug 15332: Sent DateTime object to DBIx::Class, not formatted dates If formatted dates are sent to DBIx::Class on update/insert, the date will be set as 0000-00-00 (except if the format is yyyy-mm-dd). Test plan: Use the batch patron modification tools to update the dateenrolled or dateexpiry values for at least 1 patron. Without this patch, the modified value will be updated to 0000-00-00, with this patch, the correct value will be set. Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
*** Bug 15425 has been marked as a duplicate of this bug. ***
Created attachment 46057 [details] [review] Bug 15332: Sent DateTime object to DBIx::Class, not formatted dates If formatted dates are sent to DBIx::Class on update/insert, the date will be set as 0000-00-00 (except if the format is yyyy-mm-dd). Test plan: Use the batch patron modification tools to update the dateenrolled or dateexpiry values for at least 1 patron. Without this patch, the modified value will be updated to 0000-00-00, with this patch, the correct value will be set. Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Pushed to master - thanks
Patch pushed to 3.22.x, will be in 3.22.2
This patch has been pushed to 3.20.x, will be in 3.20.8.
(In reply to Frédéric Demians from comment #12) > This patch has been pushed to 3.20.x, will be in 3.20.8. FYI: This bug also exists in the 3.18.x series, introduced in BZ-12309