Bug 15310 - Fix duplicate fines issue when changing date or time format
Summary: Fix duplicate fines issue when changing date or time format
Status: RESOLVED DUPLICATE of bug 15675
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Galen Charlton
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-04 17:10 UTC by Marc Véron
Modified: 2016-03-07 14:14 UTC (History)
2 users (show)

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


Attachments

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