Bug 13592 - Hold fee not being applied on placing a hold
Summary: Hold fee not being applied on placing a hold
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-18 18:21 UTC by Katrin Fischer
Modified: 2017-06-14 22:10 UTC (History)
14 users (show)

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


Attachments
Bug 13592: Add an option to charge for any hold placed (7.13 KB, patch)
2015-11-11 15:21 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 13592: Add an option to charge for any hold placed (7.14 KB, patch)
2015-11-13 12:41 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 13592: Add an option to charge for any hold placed (5.83 KB, patch)
2015-12-10 12:10 UTC, Sally
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 13592: Add an option to charge for any hold placed (7.22 KB, patch)
2015-12-18 18:39 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 13592: Add an option to charge for any hold placed (7.27 KB, patch)
2015-12-18 18:52 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 13592 [QA Followup] - Make the system preference description self documenting (1.44 KB, patch)
2015-12-18 18:52 UTC, Kyle M Hall
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2015-01-18 18:21:40 UTC
There was an email on the mailing list reporting problems with the hold fee set on the patron category.

I tested on master and can confirm, that no fee was set on placing a hold.

1) Administration > patron category > Add a hold fee
2) Place a hold for a patron of that category in the OPAC
3) Check the patron account - no fee was applied
Comment 1 David Roberts 2015-03-06 11:50:52 UTC
There are circumstances where the fee is applied - if the item is already on loan (or otherwise unavailable) a hold fee will be applied immediately. If the item is available, no fee is applied, even at checkout. 

It might make more sense if a fee was applied immediately for items that are available, and only applied at checkout for any items that were unavailable when the hold was placed. 

This is true for 3.18.03.000, behaviour may differ at other versions.
Comment 2 lesley.speed 2015-04-24 13:30:22 UTC
Is anyone doing any work on this as it is something we would really like fixing.
Comment 3 Jonathan Druart 2015-07-14 13:46:18 UTC
What I understand:

If it's the first hold placed on this record, the patron is not charged.
See the following (ugly) snippet of code (from C4::Reserves::GetReserveFee):

 794         if ( $allissued == 0 ) {
 795             my $rsth =
 796               $dbh->prepare("SELECT * FROM reserves WHERE biblionumber = ?");
 797             $rsth->execute($biblionumber);
 798             if ( my $rdata = $rsth->fetchrow_hashref ) {
 799             }   
 800             else { 
 801                 $fee = 0;
 802             }       
 803         }

If no reserve exists, the fee is set to 0.

This behavior seems to exist for a while.

What would be the expected behavior?

Does someone have an idea of why this condition exists?
Comment 4 Chris Cormack 2015-07-19 22:12:08 UTC
Yeah that behaviour has been there since 2000-12-19 23:45:51


If there are items on the shelf, and you aren't the first hold, you get a charge.
Was the original behaviour.

^d0374d0 (rangi 2000-12-19 23:45:51 +0000 209)       if (my $rdata = $rsth->fetchrow_hashref) { } else {                                     
^d0374d0 (rangi 2000-12-19 23:45:51 +0000 210)         $fee = 0;                                                           
^d0374d0 (rangi 2000-12-19 23:45:51 +0000 211)       }   


If they are all out, then you are not charged for the hold, someone must have changed it since then, if it now places a fee if the item is unavailable.

Basically, it should be a system preference, or an issuing rule.

But I dont think we can change behaviour that has been there for 15 years without a syspref. Or things will start unexpectedly charging, and no library wants angry borrowers.
Comment 5 Katrin Fischer 2015-07-19 22:22:42 UTC
I understand the bit about 'all out' versus 'at least one on the shelf' - but why only charge from the second hold onwards? 

Anyway, I tend to agree with Chris that we'd probably need a fix to be an option. What would make sense for me would be one of the following behaviours:

- Charge for every hold placed
- Charge for ever hold on pick-up (only filled holds)
- Charge, if the library gets an available hold for you from the shelf (without the difference mentioned above between a first or later hold)

Maybe we should ask about this on the mailing list to get a clear expectation on how this should work.

We are also documenting this not very well right now - which explains why people think it's broken:

3.2 and 3.20 manual are both stating:

If you charge patrons for placing holds on items, enter the fee amount in the 'Hold fee' field.

    Only enter numbers and decimals in this field
Comment 6 Jonathan Druart 2015-08-04 14:33:13 UTC
I can try and provide a fix if we know what we need.
Comment 7 Katrin Fischer 2015-08-04 14:59:05 UTC
I think this could be something for the mailing lists - wonder if people are aware of current behaviour and if someone can explain "why".
Comment 8 Joonas Kylmälä 2015-08-27 11:45:04 UTC
(In reply to Katrin Fischer from comment #7)
> I think this could be something for the mailing lists - wonder if people are
> aware of current behaviour and if someone can explain "why".

Now it is: https://lists.katipo.co.nz/pipermail/koha/2015-August/043527.html :)
Comment 9 Marcel de Rooy 2015-08-27 11:49:56 UTC
Please note that the sub has been refactored (without changing behavior but at least increasing readability) on bug 14702
Comment 10 Sally 2015-11-09 10:30:15 UTC
(In reply to Joonas Kylmälä from comment #8)
> (In reply to Katrin Fischer from comment #7)
> > I think this could be something for the mailing lists - wonder if people are
> > aware of current behaviour and if someone can explain "why".
> 
> Now it is: https://lists.katipo.co.nz/pipermail/koha/2015-August/043527.html
> :)

This question was asked again:  https://lists.katipo.co.nz/pipermail/koha/2015-November/044052.html

We would be extremely keen to see a behaviour change, for the reasons outlined on the e-mail list.
Comment 11 Jonathan Druart 2015-11-10 15:47:17 UTC
This looks like more than an enhancement than a bug fix, at least from my developer point of view.

Does a quick fix could do the job?
Something like a pref:
 - charge any holds
 - charge any holds if all items are issued
 - charge any holds if all items are issued and at least one hold already exists on this record # default
Comment 12 Katrin Fischer 2015-11-11 09:00:52 UTC
Hi Jonathan, I am not sure the second option is needed - but the 1 and 3 would be good I think. Preserving the current behaviour and adding what I think is the more expected scenario.
Comment 13 Jonathan Druart 2015-11-11 15:21:17 UTC Comment hidden (obsolete)
Comment 14 Marc Véron 2015-11-11 18:14:58 UTC
There is a inconsitency in the name of the syspref 

- ReserveFee 
  (in koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/circulation.pref)
- HoldFeeMode
  (in all other files)
Comment 15 Jonathan Druart 2015-11-13 12:41:56 UTC Comment hidden (obsolete)
Comment 16 Jonathan Druart 2015-11-13 12:42:28 UTC
(In reply to Marc Véron from comment #14)
> There is a inconsitency in the name of the syspref 

Sorry about that, last minute change :-/
Comment 17 Sally 2015-12-09 16:10:26 UTC
Hold fee is applied if all items for the record are issued
and at least one hold already exists on the record.  This patch adds the ability to charge for any hold placed, regardless of the conditions.

Test plan:
1) Execute the updatedb entry to insert the new pref
2) Confirm that the behavior is the same as before applying this patch
3) Change the HoldFeeMode pref to 'always'
4) Note that the fee is applied for any hold placed

This patch has been tested and works as expected.
Comment 18 Sally 2015-12-10 12:09:30 UTC
Test plan:
1) Execute the updatedb entry to insert the new pref
2) Confirm that the behavior is the same as before applying this patch
3) Change the HoldFeeMode pref to 'always'
4) Note that the fee is applied for any hold placed

Sign off on Jonathan's patch.
Signed-off-by: Sally Healey <sally.healey@cheshiresharedservices.gov.uk>
Comment 19 Sally 2015-12-10 12:10:35 UTC Comment hidden (obsolete)
Comment 20 Kyle M Hall 2015-12-18 18:39:14 UTC Comment hidden (obsolete)
Comment 21 Kyle M Hall 2015-12-18 18:52:15 UTC
Created attachment 45864 [details] [review]
Bug 13592: Add an option to charge for any hold placed

Currently the fee is applied on if all items for the record are issued
and at least one hold already exists on the record.
This patch does not give a complete answer to the problem (see
discussion on bug 13592 for the other user's expectations).
It only adds the ability to charge for any hold placed regardless of the
conditions.

Test plan:
1) Execute the updatedb entry to insert the new pref
2) Confirm that the behavior is the same as before applying this patch
3) Change the HoldFeeMode pref to 'always'
4) Note that the fee is applied for any hold placed

Signed-off-by: Sally Healey <sally.healey@cheshiresharedservices.gov.uk>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 22 Kyle M Hall 2015-12-18 18:52:24 UTC
Created attachment 45865 [details] [review]
Bug 13592 [QA Followup] - Make the system preference description self documenting

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 23 Kyle M Hall 2015-12-31 16:07:19 UTC
Pushed to master, thanks Jonathan!