Summary: | Lost fines may not be refunded if another patron has a writeoff for the same item | ||
---|---|---|---|
Product: | Koha | Reporter: | Nick Clemens (kidclamp) <nick> |
Component: | Fines and fees | Assignee: | Bugs List <koha-bugs> |
Status: | CLOSED FIXED | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | cbrannon, jonathan.druart, josef.moravec, martin.renvoize, tomascohen |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22563 | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Bug Depends on: | 22563 | ||
Bug Blocks: | |||
Attachments: | Bug 22377: Add test case |
Description
Nick Clemens (kidclamp)
2019-02-20 14:35:23 UTC
Do you have the rule defined? It seems that it is not created on install. (In reply to Jonathan Druart from comment #1) > Do you have the rule defined? It seems that it is not created on install. Which rule? I believe the problem is in the code for _FixAccountForLostAndReturned my $accountlines = Koha::Account::Lines->search( { itemnumber => $itemnumber, accounttype => { -in => [ 'L', 'Rep', 'W' ] }, }, { order_by => { -desc => [ 'date', 'accountno' ] } } ); We order by date and accountno - so a more recent writeoff will be found insetad of the lost fine On second thoughts.. why do we look for 'W' at all in that query?.. 'W' = Writeoff == Credit.. should we not be looking solely for the 'L' (and/or 'LR') debt line? I'm working on a test for this at the tip of my accounts branch over here: https://github.com/PTFS-Europe/koha/compare/accounts_all...PTFS-Europe:bug_22377 Currently however I'm struggling to replicate the problem. Created attachment 87605 [details] [review] Bug 22377: Add test case Attached my attempt to write a test for this.. anyone is welcome to take over as I couldn't replicate the issue. Would like to see this move forward. This is an active problem. Test still applies and I still can't replicate the issue... Reducing severity for now until someone can come up with a failing test case. The tests are constructed correctly, however, the problematic code has changed. The search as I describe has been removed, it now looks for a status of undef or '!= returned' AND specifically for lost fines Additionally, a write-off no longer gets an itemnumber, so we can't accidentally get the wrong fines. Fixed by bug 22563 |