Bug 7075 - Fine in days values are returned for patrons with past overdues when fine in days is set to 0
Summary: Fine in days values are returned for patrons with past overdues when fine in ...
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: master
Hardware: All All
: P3 trivial (vote)
Assignee: Chris Cormack
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-21 14:16 UTC by Owen Leonard
Modified: 2014-12-07 20:02 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
Proposed fix (991 bytes, patch)
2011-10-21 14:28 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 7075 : Alternative patch to solve the finedays = 0 issue (816 bytes, patch)
2011-11-03 22:03 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 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.