Bug 7075

Summary: Fine in days values are returned for patrons with past overdues when fine in days is set to 0
Product: Koha Reporter: Owen Leonard <oleonard>
Component: CirculationAssignee: Chris Cormack <chris>
Status: CLOSED INVALID QA Contact: Bugs List <koha-bugs>
Severity: trivial    
Priority: P3 CC: chris, gmcharlt, katrin.fischer, paul.poulain
Version: master   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: Proposed fix
Bug 7075 : Alternative patch to solve the finedays = 0 issue

Description Owen Leonard 2011-10-21 14:16:08 UTC
When Members.pm checks to see whether a particular patron can check out, it checks for issuingrules.finedays "WHERE finedays IS NOT NULL." If the user has created a rule via Circulation and fines rules, finedays will always be 0 even if an empty value has been submitted. This causes Members::IsMemberBlocked to return a value when it should not.

[09:57]	<sekjal>	IsMemberBlocked checks for finedays IS NOT NULL
[09:58]	<oleonard>	...and it's 0.
[09:58]	<sekjal>	so, if you have finedays = 0 in any of your rules, it'll 
                        trigger
[09:59]	<sekjal>	so, in that case, it'll just take the date difference 
                        between the returndate, and the current date
[09:59]	<sekjal>	which means it would grow to 44 tomorrow
[09:59]	<sekjal>	and so on
[09:59]	<sekjal>	that's.... bad
[09:59]	<libsysguy>	^^
[09:59]	<oleonard>	And you can't set finedays to null when editing an 
                        issuing rule
[10:00]	<libsysguy>	so we could change that check or null or 0
[10:00]	<libsysguy>	and it would fix your issue right
[10:00]	<sekjal>	yes, that's the fix
[10:00]	<sekjal>	one more line to the SQL
[10:00]	<sekjal>	"AND finedays != 0"

http://stats.workbuffer.org/irclog/koha/2011-10-21#i_795577
Comment 1 Owen Leonard 2011-10-21 14:28:08 UTC Comment hidden (obsolete)
Comment 2 Owen Leonard 2011-10-21 16:11:07 UTC
Looks like the trigger for the manifestation of this bug (blocked checkout when fine in days is not set) is only caused by a returndate in old_issues set some time in the future. In this case it was a result of manual data manipulation for the purpose of testing, so it seems unlikely to happen in the normal course of operation.
Comment 3 Chris Cormack 2011-11-03 22:03:34 UTC
I think safer, to do 

WHERE finedays IS NOT NULL AND finedays > 0

Sometimes null behaves weirdly in some database engines.

Have submitted a different patch doing that
Comment 4 Chris Cormack 2011-11-03 22:03:42 UTC
Created attachment 6169 [details] [review]
Bug 7075 : Alternative patch to solve the finedays = 0 issue
Comment 5 Katrin Fischer 2011-12-18 08:03:49 UTC
I tried to reproduce the problem:
- set circulation rules and made sure finedays was 0 in the database
- checked out an item, returned it
- set the returndate in old_issues to a date in the future

What did I miss?
Comment 6 Paul Poulain 2012-02-03 08:44:58 UTC
Setting status to "in discussion", if no one is able to reproduce the problem now, should be closed
Comment 7 Paul Poulain 2012-03-30 10:21:11 UTC
Chris / Owen = can you still reproduce the problem (seems katrin can't) ? If no, i'll RESO/INVALID this bug
Comment 8 Galen Charlton 2013-08-12 15:59:55 UTC
This bug was made moot by the patch for bug 6328.  Setting to RESO/INVALID.