Bug 15332

Summary: ModMember not interpreting dates (Batch patron modification)
Product: Koha Reporter: Nick Clemens <nick>
Component: ToolsAssignee: Jonathan Druart <jonathan.druart>
Status: CLOSED FIXED QA Contact: Marcel de Rooy <m.de.rooy>
Severity: critical    
Priority: P5 - low CC: brendan, costalc, danielle, f.demians, jonathan.druart, julian.maurice, liz, m.de.rooy, mtj
Version: master   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12309
Change sponsored?: --- Patch complexity: Trivial patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on: 12633    
Bug Blocks: 15607    
Attachments: Bug 15332: Sent DateTime object to DBIx::Class, not formatted dates
Bug 15332: Sent DateTime object to DBIx::Class, not formatted dates
Bug 15332: Sent DateTime object to DBIx::Class, not formatted dates
Bug 15332: Sent DateTime object to DBIx::Class, not formatted dates

Description Nick Clemens 2015-12-08 17:56:33 UTC
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
Comment 1 Danielle Elder 2015-12-09 14:58:02 UTC
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 |
Comment 2 Danielle Elder 2015-12-09 15:02:21 UTC
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 |
Comment 3 Jonathan Druart 2015-12-18 15:04:28 UTC Comment hidden (obsolete)
Comment 4 Jonathan Druart 2015-12-18 15:06:00 UTC
This has certainly been introduced by bug 12633
Comment 5 Jonathan Druart 2015-12-18 15:08:58 UTC
I have quickly checked the other calls and they look good.
Comment 6 Nick Clemens 2015-12-18 20:55:36 UTC Comment hidden (obsolete)
Comment 7 Marcel de Rooy 2015-12-24 10:32:14 UTC Comment hidden (obsolete)
Comment 8 Marc Véron 2015-12-27 19:04:59 UTC
*** Bug 15425 has been marked as a duplicate of this bug. ***
Comment 9 Brendan Gallagher 2015-12-30 02:49:31 UTC
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>
Comment 10 Brendan Gallagher 2015-12-30 02:49:53 UTC
Pushed to master - thanks
Comment 11 Julian Maurice 2015-12-31 08:34:41 UTC
Patch pushed to 3.22.x, will be in 3.22.2
Comment 12 Frédéric Demians 2015-12-31 18:28:09 UTC
This patch has been pushed to 3.20.x, will be in 3.20.8.
Comment 13 Mason James 2016-01-19 19:42:08 UTC
(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