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
[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
[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"
Created attachment 6016 [details] [review]
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.