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, 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
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 |