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
Created attachment 6016 [details] [review] Proposed fix Changes "WHERE finedays IS NOT NULL" to "WHERE finedays > 0" in order to accomodate 0 values in issuingrules.finedays.
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.
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
Created attachment 6169 [details] [review] Bug 7075 : Alternative patch to solve the finedays = 0 issue
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?
Setting status to "in discussion", if no one is able to reproduce the problem now, should be closed
Chris / Owen = can you still reproduce the problem (seems katrin can't) ? If no, i'll RESO/INVALID this bug
This bug was made moot by the patch for bug 6328. Setting to RESO/INVALID.