Bug 8182 - Problem with overdue fine calculations after upgrade
Summary: Problem with overdue fine calculations after upgrade
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Database (show other bugs)
Version: 3.8
Hardware: All All
: P1 - high major (vote)
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
: 8165 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-06-01 18:28 UTC by Kyle M Hall
Modified: 2013-12-05 19:57 UTC (History)
5 users (show)

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


Attachments
Bug 8182 - Problem with overdue fine calculations after upgrade (21.48 KB, patch)
2012-06-01 18:30 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 8182 - Problem with overdue fine calculations after upgrade (1.83 KB, patch)
2012-06-01 18:32 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 8182 - Problem with overdue fine calculations after upgrade (1.87 KB, patch)
2012-06-01 19:37 UTC, Chris Cormack
Details | Diff | Splinter Review
Bug 8182 - Problem with overdue fine calculations after upgrade (1.87 KB, patch)
2012-06-01 19:38 UTC, Chris Cormack
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2012-06-01 18:28:16 UTC
Items that were overdue and still out as of 5/26 (date of Upgrade) were charged
overdue fines as of 5/26.  When the items DO come back, the overdue fines are
calculated again from the due date to the date of checkin.  Therefore the
patron is being charged double overdue fines from the original date up to 5/26.

This is caused by issues.date_due being changed to a datetime, with the hour/minute/secons time portion defaulting to 00:00:00. It should be 23::50::00 instead.
Comment 1 Kyle M Hall 2012-06-01 18:30:07 UTC Comment hidden (obsolete)
Comment 2 Kyle M Hall 2012-06-01 18:32:21 UTC Comment hidden (obsolete)
Comment 3 Melia Meggs 2012-06-01 19:26:38 UTC
*** Bug 8165 has been marked as a duplicate of this bug. ***
Comment 4 Chris Cormack 2012-06-01 19:32:41 UTC
Are we sure we can't fix those who have upgraded already too? With an update statement?
Comment 5 Chris Cormack 2012-06-01 19:37:33 UTC Comment hidden (obsolete)
Comment 6 Chris Cormack 2012-06-01 19:38:05 UTC
Created attachment 9895 [details] [review]
Bug 8182 - Problem with overdue fine calculations after upgrade

Items that were overdue and still out as of 5/26 (date of Upgrade) were charged
overdue fines as of 5/26.  When the items DO come back, the overdue fines are
calculated again from the due date to the date of checkin.  Therefore the
patron is being charged double overdue fines from the original date up to 5/26.

This is caused by issues.date_due being changed to a datetime, with the
hour/minute/secons time portion defaulting to 00:00:00. It should be 23::50::00 instead.

This is an unusual patch as it modifies a previous database update. This
make sense because if a install has already been updated past the db rev
update, this fix will be too late. It will only help those that have not
updated past that db revision.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Comment 7 Chris Cormack 2012-06-01 19:39:22 UTC
Signed off the fix, it will fix anyone upgrading from 3.6/3.4 .. but I think we still need a follow up to catch the ones who already have. Or at least a nice easy recipe for them to follow to clean up.
Comment 8 Chris Cormack 2012-06-01 19:40:11 UTC
NOTE: This is only a problem on upgrades, fresh installs are ok

I'd definitely like it in before the 3.8.2 release
Comment 9 Ian Walls 2012-06-04 17:25:33 UTC
Simple patch to set the due time to the end of the day, rather than the beginning.  Marking as Passed QA.

I don't think there is going to be a good way to repeal any fines erroneously assessed in this way; while accountlines does have a timestamp field, it is updated every time the fine increments or is paid down, so we lose data about when the overdue was originally assessed.  This needs to be fixed with a rebuilding of the accounts system, but that's beyond the scope of this particular issue.

To clean up, the key variable would be the date of upgrade... anything due on that date could be credited 1 day's worth against it's overdue value... but this doesn't factor in after-due renewals, or materials that have already been returned (paid or not).
Comment 10 Paul Poulain 2012-06-05 14:05:16 UTC
Patch pushed, I agree it will be hard to fix already upgraded libraries.

One question: why have you defined 23:59:00, and not 23:59:59 ?
Comment 11 Kyle M Hall 2012-06-05 16:13:41 UTC
Either way should be functionally equivalent, at least until we implement fines at the per-second level ; )

Kyle

(In reply to comment #10)
> Patch pushed, I agree it will be hard to fix already upgraded libraries.
> 
> One question: why have you defined 23:59:00, and not 23:59:59 ?
Comment 12 Chris Cormack 2012-06-05 20:02:11 UTC
Pushed to 3.8.x, will be in 3.8.2