| 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: | Circulation | Assignee: | Chris Cormack <chris> |
| Status: | CLOSED INVALID | QA Contact: | Bugs List <koha-bugs> |
| Severity: | trivial | ||
| Priority: | P3 | CC: | chris, gmcharlt, paul.poulain |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Crowdfunding goal: | 0 |
| Patch complexity: | --- | Documentation contact: | |
| Documentation submission: | Text to go in the release notes: | ||
| Version(s) released in: | Circulation function: | ||
| Attachments: |
Proposed fix
Bug 7075 : Alternative patch to solve the finedays = 0 issue |
||
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 |
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