Summary: | Lost Items Not Removed From Patron's Account When Charge is Paid | ||
---|---|---|---|
Product: | Koha | Reporter: | Chris Slone <cslone> |
Component: | Circulation | Assignee: | Martin Renvoize (ashimema) <martin.renvoize> |
Status: | RESOLVED DUPLICATE | QA Contact: | Testopia <testopia> |
Severity: | major | ||
Priority: | P5 - low | CC: | andrew, azucena.aguayo, gmcharlt, hannah.co, kelly, kyle.m.hall, lisettepalouse+koha, martin.renvoize |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8016 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22982 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24474 |
||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: |
Description
Chris Slone
2017-07-05 15:03:36 UTC
Our library just migrated to Koha and we already run into this bug and the problems associated with items not properly getting removed from the patron's account. Is this bug on the radar to get fix anytime soon? The work around of using only the "pay" button per lost item is tedious and difficult to enforce when we have a large group of PT employee on the front desks using the system. If Koha has X ways to set an item to lost And X ways to pay for the lost fee Then shouldn't the result be the same: fee paid > item off the patron account Our library cares about this bug. Having to use the 'pay' button for each fee on a patron account is tedious and time consuming. Some conditions that could cause this were eliminated in bug 22982, which was backported into 19.05.01. However, I've got an example from a lost item payment made in 19.05.06. Hi Andrew, As I'm working on bug 24474 which refines and corrects some issues introduced in bug 22982 I'd be interested to know if you can replicate any of these issues against master at the moment? I was about to mark this one as RESOLVED FIXED as I felt 22982 covered all cases... but if there's still ways to get into this state which I'm unaware of then it needs to stay open and we need to clarify what cases are still open to lead to this situation. Thanks in advance, Martin I have not been able to recreate this on master or 19.05. The example we've got is pretty mystifying. I believe that one of the bugs shown in the See Also section (8016, 22982, 24474) may have corrected this. This bug was submitted as a related but separate issue to 8016. |