Bug 15310

Summary: Fix duplicate fines issue when changing date or time format
Product: Koha Reporter: Marc Véron <veron>
Component: Architecture, internals, and plumbingAssignee: Galen Charlton <gmcharlt>
Status: RESOLVED DUPLICATE QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: katrin.fischer, kyle
Version: Main   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15076
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15312
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:

Description Marc Véron 2015-12-04 17:10:04 UTC
Changing the sysprefs 'dateformat' and/or 'TimeFormat' on a production server with overdue items that are accruing fines can result in duplicate fines.

It happens when the system has to decide wether to update an existing fine or to add a new fine.

It is related to C4/Overdues.pm line 538 that parses the fines description for a date in the current syspref date format ($due_qr). 
         
if ($rec->{itemnumber} == $itemnum && $rec->{description} =~ /$due_qr/) 

If the dateformat is changed, parsing will not find the date in previous fines and an extra fine will be applied.

It is not possible to automatically parse for all date formats since dd/mm/yyyy and mm/dd/yyyy can be ambiguous. The system needs an information about what the previous date format was (if it changed).

To bridge the issue until we have a rewrite of the accounts system ready, the previous date- / and time format can be indicated in additional sysprefs.
Comment 1 Katrin Fischer 2015-12-04 17:32:19 UTC
Hm, not sure about the system prefernece idea - what if someone changes it multiple times? forgets to keep track of the changes? It would also need the date it was changed etc. It's tricky.
Could we do a global switch to the db date format and fix it for display maybe?
I think a big warning and a script to fix the entries in the accountlines table to the new dateformat would be ok for me until we can move the date totally out of the description.
Comment 2 Marc Véron 2015-12-04 18:29:05 UTC
Thanks for the comment, Katrin.

You are right, it is very tricky and errorprone to fix the issue.

We have the script fix_accountlines_date.pl.

However, the current version handles only 'us' and 'metric' as previous date formats.
Comment 3 Katrin Fischer 2015-12-04 18:31:20 UTC
I think it might be worth fixing the script - what do you think?
Comment 4 Kyle M Hall 2016-03-07 14:14:36 UTC
I do believe that bug 15675 fixes this once and for all! That bug changed the behavior such that the fines updater no longer relies on the description for fine selection!

I think the only thing left to do is to remove the warnings from the system preferences.

*** This bug has been marked as a duplicate of bug 15675 ***