Bug 15332 - ModMember not interpreting dates (Batch patron modification)
Summary: ModMember not interpreting dates (Batch patron modification)
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Tools (show other bugs)
Version: master
Hardware: All All
: P5 - low critical (vote)
Assignee: Jonathan Druart
QA Contact: Marcel de Rooy
URL:
Keywords:
: 15425 (view as bug list)
Depends on: 12633
Blocks: 15607
  Show dependency treegraph
 
Reported: 2015-12-08 17:56 UTC by Nick Clemens
Modified: 2019-06-27 09:24 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 15332: Sent DateTime object to DBIx::Class, not formatted dates (1.45 KB, patch)
2015-12-18 15:04 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 15332: Sent DateTime object to DBIx::Class, not formatted dates (1.50 KB, patch)
2015-12-18 20:55 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 15332: Sent DateTime object to DBIx::Class, not formatted dates (1.60 KB, patch)
2015-12-24 10:32 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Bug 15332: Sent DateTime object to DBIx::Class, not formatted dates (1.63 KB, patch)
2015-12-30 02:49 UTC, Brendan Gallagher
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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