Bug 5211 - marking lost (long overdue) not charging fines
Summary: marking lost (long overdue) not charging fines
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: 3.6
Hardware: All All
: PATCH-Sent (DO NOT USE) major (vote)
Assignee: Srdjan Jankovic
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-09 13:25 UTC by Nicole C. Engard
Modified: 2013-12-05 19:57 UTC (History)
5 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
patch (3.50 KB, patch)
2011-12-02 00:36 UTC, Srdjan Jankovic
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2010-09-09 13:25:17 UTC
It used to be that if you manually marked an item as Long Overdue (Lost) it would automatically charge the patron the replacement price for the item. This is not happening now unless you use the cron job to mark things long overdue and lost.  It should happen in both instances.
Comment 1 Melia Meggs 2011-11-30 00:56:48 UTC
Nicole, is this still a problem, or was it fixed with Bug 5533?
Comment 2 Srdjan Jankovic 2011-12-02 00:36:30 UTC
Created attachment 6500 [details] [review]
patch

Modified the LostItem() subroutine to take a "charge" parameter, and altered any usage of that subroutine to pass said param (to maintain consistency). That'll lay some of the groundwork while we get the larger issue of the admin interface worked out.
Comment 3 Ian Walls 2011-12-02 13:13:07 UTC
Adds necessary new param to subroutine, and changes all calls to LostItem to pass this, so behaviour remains unchanged.  Opens doors for later fixes to "lost" logic.  Marking as Signed off and Passed QA in one go.
Comment 4 Paul Poulain 2011-12-03 06:20:07 UTC
Before pushing, a question: I don't understand why we need a 3rd parameter in the LostItem sub. Is there a case where we don't want to add fines when marking an item lost ?
After applying the patch I can't find a call without this parameter.
So, I feel the parameter is not needed and add useless complexity to the API.

Other question: can we now mark LostItem and forgive fine ? I feel no (which is not a problem, just to be sure)
Comment 5 Katrin Fischer 2011-12-03 06:39:06 UTC
I think there are some scenarios where you don't want to charge the fine immediately. For example: Claims returned.
In this case the library normally searches for the book on its shelves to make sure there was not something missed on return. If the book can not be found, the patron will be charged for the item later on. 
I don't think Koha works like that right now, but with the parameter we could treat different lost status differently again. If I understand it correctly.
Comment 6 Ian Walls 2011-12-03 14:13:19 UTC
Paul,


I've asked this to be done based on requests from NEKLS and VOKAL (two of ByWater's large consortia).  When bug 5533 was incorporated, it changed the semantics of the various "lost" statuses.  Before, certain values would do different things, depending on what triggered them.  Some libraries like this, and came to depend on it.

In my opinion, an Authorized Value shouldn't be any more than a label on it's own; there is not mechanism for defining any additional actions or meaning at the AV level.  But, marking something as "lost" is more than just labeling it.  As of right now, it means always charging the patron for the material and sometimes returning it (if it's checked out).  This patch will allow for us to sometimes charge and sometimes return.  Right now, there is no change in functionality with this patch, but this opens those doors for us down the road.
Comment 7 Paul Poulain 2011-12-06 10:38:14 UTC
Ian & Katrin, thanks for your answers.

patch now pushed, please test

Also, please open another bug (ENH ?) to suggest the improved behaviour (let one choose to apply fine or not)
Comment 8 Jared Camins-Esakov 2012-05-23 12:05:08 UTC
Included in 3.6 prior to 3.6.5.