[Bug 8338] New: fines not cleared with dropbox mode
From Nicole: It was my understanding that checking the dropbox mode option on
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8338 Priority: P5 - low Change sponsored?: --- Bug ID: 8338 CC: gmcharlt@gmail.com, kyle.m.hall@gmail.com Assignee: koha-bugs@lists.koha-community.org Summary: fines not cleared with dropbox mode Severity: enhancement Classification: Unclassified OS: All Reporter: melia@bywatersolutions.com Hardware: All Status: NEW Version: rel_3_8 Component: Circulation Product: Koha the check in screen made the due date effectively the last day the library was open and as such wiped out fines for the extra day. It appears that is not the case. Fines for the item being late remain on the patron's account. The only way around this is to 'forgive fines' when using dropbox mode, but that forgives all fines and really we only want to forgive one day of fines. So if the fines script has already run, then fines are not wiped. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8338 Melia Meggs <melia@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |5644 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8338 Nicole C. Engard <nengard@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nengard@gmail.com Severity|enhancement |normal --- Comment #1 from Nicole C. Engard <nengard@gmail.com> --- changing from enhancement to bug - since the understanding is that dropbox mode is used to push the 'returned day' back and as such shouldn't charge fines for the days past the 'checkin day' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8338 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris@bigballofwax.co.nz Severity|normal |enhancement --- Comment #2 from Chris Cormack <chris@bigballofwax.co.nz> --- Nope the dropbox mode exists only to change the day of return to the previous day. Adding a new feature to remove fines is certainly an enhancement. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8338 --- Comment #3 from Nicole C. Engard <nengard@gmail.com> --- What's the point of changing the day ... except to get rid of the fines? That at least is the point here in the US. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8338 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com --- Comment #4 from Kyle M Hall <kyle@bywatersolutions.com> --- I tend to agree with Nicole, I had always assumed that dropbox mode was backdating the return date to yesterday so that fines would be generated as if it had been returned the day before. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8338 Colin Campbell <colin.campbell@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |colin.campbell@ptfs-europe. | |com --- Comment #5 from Colin Campbell <colin.campbell@ptfs-europe.com> --- There does seem to be a common expectation amongst users that dropbox mode clears fines in some way. And subsequently they find it to be behaving inconsistently. The behaviour does need documenting as it seems to be adding confusion. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8338 --- Comment #6 from Chris Cormack <chris@bigballofwax.co.nz> --- Probably doesn't matter whether it's an enhancement or bug unless a patch to change it actually exists. But it is working as designed, adding the ability for it to wipe fines is therefore an enhancement. But yeah without a patch its moot anyway. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8338 Aaron Sakovich <asakovich@hmcpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |asakovich@hmcpl.org --- Comment #7 from Aaron Sakovich <asakovich@hmcpl.org> --- As an end-user, I've got to agree with Melia, Nicole, and Kyle. This is totally unexpected behavior, and I can't quite wrap my head around the business rule that would have resulted in this program logic. Maybe that's just me, but I don't think so. As Chris says, whether you call this a bug or enhancement is really moot; the functionality is not in there and we *really* need this functionality. Erasing all fines on an item when we're just trying to compensate for the fact that we were closed yesterday is not the way we do business. If there is a use case where all fines should be wiped because a branch was closed yesterday, then perhaps we should have radio buttons to select either "Forgive all fines" vs. "Forgive fines while closed", but we at least need the option at our library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8338 --- Comment #8 from Chris Cormack <chris@bigballofwax.co.nz> --- (In reply to Aaron Sakovich from comment #7)
As an end-user, I've got to agree with Melia, Nicole, and Kyle. This is totally unexpected behavior, and I can't quite wrap my head around the business rule that would have resulted in this program logic. Maybe that's just me, but I don't think so.
One thing you learn with working with libraries, is that assuming that the way your library does it is the same way others do it is the single biggest mistake you can make.
As Chris says, whether you call this a bug or enhancement is really moot; the functionality is not in there and we *really* need this functionality. Erasing all fines on an item when we're just trying to compensate for the fact that we were closed yesterday is not the way we do business.
What I actually said is talking about if it's a bug or an enhancement is moot, until someone either pays someone to, or writes code themselves to change it. IE without a patch, nothing will change, no matter how we label it.
If there is a use case where all fines should be wiped because a branch was closed yesterday, then perhaps we should have radio buttons to select either "Forgive all fines" vs. "Forgive fines while closed", but we at least need the option at our library.
Awesome, I assume you will be working on a patch for this? Or paying someone to do this for you? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8338 --- Comment #9 from Aaron Sakovich <asakovich@hmcpl.org> --- (In reply to Chris Cormack from comment #8)
One thing you learn with working with libraries, is that assuming that the way your library does it is the same way others do it is the single biggest mistake you can make.
Totally agree, which is why I tried to ensure I personalized my comment. But then, that also goes the other way -- just because (it appears) some libraries may want to wipe all their fines doesn't mean everyone follows that business rule.
What I actually said is talking about if it's a bug or an enhancement is moot, until someone either pays someone to, or writes code themselves to change it.
If I misled you to thinking I did not understand your point, I apologize, as I absolutely do -- again, I tried to express my perspective by saying "we", as in HMCPL. I tempered that with questioning if the existing business logic was indeed a valid use case, which if no one uses it this way, why is it coded thus? If no one uses a feature because the business logic does not reflect the real world, is it really a feature, or a bug? And yes, I would be okay if numLibraries ge 1. I'd even be okay with anecdotal evidence. Like I said, I (personally, and as a representative of HMCPL) was just having trouble wrapping my head around this business logic.
Awesome, I assume you will be working on a patch for this? Or paying someone to do this for you?
Indeed, I've been working on this angle for a few weeks since discovering this "feature". Thanks for your time and consideration. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8338 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |katrin.fischer@bsz-bw.de Version|3.8 |master Resolution|--- |DUPLICATE --- Comment #10 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- It looks like bug 10694 will fix this: "Sometimes libraries need to backdate returns further back in time than Koha's dropbox mode will allow. The returns backdating will check in an item as if it had been returned on the specified date, and will reduce any fine accordingly." *** This bug has been marked as a duplicate of bug 10694 *** -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8338 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|DUPLICATE |--- --- Comment #11 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hm, on second thought might not be quite the same, please check if the new feature on bug 10694 is a fix for you. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8338 --- Comment #12 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Katrin Fischer from comment #10)
It looks like bug 10694 will fix this:
"Sometimes libraries need to backdate returns further back in time than Koha's dropbox mode will allow. The returns backdating will check in an item as if it had been returned on the specified date, and will reduce any fine accordingly."
*** This bug has been marked as a duplicate of bug 10694 ***
Yes, as the author of bug 10694 I believe that it will effectively resolve this bug. The only difference is that feature will require you to select the return date rather than having it decided for you automatically. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org