If a patron has over time accumulated fines greater than the amount defined in MaxFine, the patron will never get more fines even if they have previously paid off those fines. This bug was introduced by the patch for Bug 7420.
Created attachment 17372 [details] [review] Bug 10030 - MaxFines checks against amount, not amount outstanding If a patron has over time accumulated fines greater than the amount defined in MaxFine, the patron will never get more fines even if they have previously paid off those fines. This bug was introduced by the patch for Bug 7420. Test Plan: 1) Create a patron 2) Create a fine of 10.00 for that patron 3) Pay off the fine 4) Set MaxFines to 5.00 5) Check out an item to the patron, backdate the due date so the item should generate fines. 6) Run fines.pl, observe that no fine was created 7) Apply the patch 8) Rerun fines.pl 9) Observe that the fine was created correctly
Created attachment 17568 [details] [review] Bug 10030 - MaxFines checks against amount, not amount outstanding If a patron has over time accumulated fines greater than the amount defined in MaxFine, the patron will never get more fines even if they have previously paid off those fines. This bug was introduced by the patch for Bug 7420. Test Plan: 1) Create a patron 2) Create a fine of 10.00 for that patron 3) Pay off the fine 4) Set MaxFines to 5.00 5) Check out an item to the patron, backdate the due date so the item should generate fines. 6) Run fines.pl, observe that no fine was created 7) Apply the patch 8) Rerun fines.pl 9) Observe that the fine was created correctly Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Working on this.
Kyle, I see some strange behaviour with your patch applied: System preferences: maxfine: empty Circulation rules: mpl-staff-books maxfine 15.00 fine 5.00 grace period: 0 interval 1 Logged in branch: mpl Home library of items: mpl Patron home library: mpl I set the due date to about 8-9 days ago using the specify due date feature. I then returned the book using the checkbox on the checkout tab. Suddenly I have credit of 15.00 on my patron account... Couldn't repeat that switching back to master. Could you please check?
Now I can't reproduce on master too - or with your patch. It happened 3 times, I have no time now to figure out what's going on there. Someone taking a closer look would be appreciated.
The problems I experienced were related to the fact that you should use 'new' items/due dates to make sure this works consistently. I am continuing the tests, but reading the code of the sub I couldn't help wondering - do we really want to count in Sundry fines? http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=C4/Overdues.pm;h=bc1c7a77dbfe451180f6d4262e0351152336b197;hb=1b877167f5231f7eef6c7f82cba9322bdba0dbac#l502
Looking at this one now..
Created attachment 18156 [details] [review] Bug 10030 - MaxFines checks against amount, not amount outstanding If a patron has over time accumulated fines greater than the amount defined in MaxFine, the patron will never get more fines even if they have previously paid off those fines. This bug was introduced by the patch for Bug 7420. Test Plan: 1) Create a patron 2) Create a fine of 10.00 for that patron 3) Pay off the fine 4) Set MaxFines to 5.00 5) Check out an item to the patron, backdate the due date so the item should generate fines. 6) Run fines.pl, observe that no fine was created 7) Apply the patch 8) Rerun fines.pl 9) Observe that the fine was created correctly Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 18157 [details] [review] Bug 10030: QA Followup for trivial false warning detected while testing Moving the warn line below the line that returns if amount<=0. If amount<=0, a false warn is now raised because of the return after it. We should only warn here if we do not return. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Tested with fines.pl on overdue. Before this patch: Reducing fine for item 199709 borrower 23 from 44 to -1 - MaxFine reached. This did not happen however because of the return. After this change: no false warning.
QA Comment: Tested. Works. Added a trivial followup too for false warning raised (detected while testing this). Simple code change looks good. The question Katrin raised: > I am continuing the tests, but reading the code of the sub I couldn't help wondering - do we really want to count in Sundry fines? This question is certainly valid, but imo falls outside the scope of this report. This patch just fixes the wrongly used column in adding the total amount. Passed QA
Marcel, totally agreed - thx for QA'ing! :) I will try to write up a new bug for the other problem.
This patch has been pushed to master and 3.12.x.