Bug 9190

Summary: Problem with holds - allow place a hold without all items checked out
Product: Koha Reporter: Vitor Fernandes <vfernandes>
Component: Hold requestsAssignee: Bugs List <koha-bugs>
Status: RESOLVED DUPLICATE QA Contact:
Severity: enhancement    
Priority: P1 - high CC: gmcharlt, jonathan.druart, katrin.fischer, koha, kyle.m.hall, marjorie.barry-vila, Susanne.Jerger, vinod_librarian
Version: Main   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6837
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11481
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:

Description Vitor Fernandes 2012-12-03 12:43:16 UTC
The objective is only to allow a patron to place a hold only when all items are checked out. The hold will be placed in the next item available.

If there isn't any checked out items I can't place a hold, which is fine
If all items are checked out I can place a hold, which is fine
If 1 items of X items are checked out I can place a hold, which isn't what I pretend

System preferences:

- OPACItemHolds = don't allow
- AllowOnShelfHolds = don't allow
Comment 1 Katrin Fischer 2012-12-03 12:53:00 UTC
Hi Vitor, 

I think the problem might be more difficult than that. For examle you have to factor in multiple branches. 

What is the right condition to allow a hold?

- All items at all branches are checked out, that the user is allowed to checkout
- All items at the patron's home library are checked out, that the user is allowed to checkout
- ?

There are also settings in the circulation rules to define, what is 'holdable' from the current branch, any branch, not at all etc.

Maybe we could say currently the user is to blame, if he puts a hold on a title with available items. If the library doesn't AllowOnShelfHolds noone is going to pull the book for him/her and he/she will have to wait for the 1 checked out item to be returned?

Mostly guessing, one of the hold experts might now.
Comment 2 Vitor Fernandes 2012-12-03 13:11:08 UTC
Hi Katrin,

Im my case the problem appears when:

 - All items at the patron's home library are checked out, that the user is allowed to checkout

Of course that the use has the blame, because there are items available. But it would be nice to block him to place holds in this case.
Comment 3 Katrin Fischer 2012-12-03 13:21:08 UTC
Hi Vitor, only to clarify: Do you mean not all items are checked out but hold is allowed? Or are they all checked out?
Comment 4 Vitor Fernandes 2012-12-03 14:29:31 UTC
Katrin,

What I want is only allow holds when all items of the library are checkout.
What happen is that the patron is able to place holds when at least one item is checked out.
Comment 5 vinod 2013-01-21 07:10:32 UTC
This requirement seems some time good, but if the items is multi-volume  which cataloged under one bibliography, than in that case this option is needed to place hold on that particulate Pt./Vol. etc.
Comment 6 Katrin Fischer 2014-08-06 14:14:37 UTC
I think it could be a rule to allow title level holds only, when all items from the home library are checked out and item level holds on all items checked out?
Maybe we can't come up with a perfect solution, but having a switch to implement what Viktor suggested would be good:

Optionally, only allow holds, if all items of the patron's home library are checked out. 

Maybe as a third option to AllowOnShelfHolds?
Comment 7 Katrin Fischer 2014-08-06 14:19:44 UTC
Looking at this again, I think it could be a dupicate to 6837.
Comment 8 Jonathan Druart 2015-07-10 14:30:36 UTC
This is not critical but an enhancement request.

Vitor, could you confirm that what you mean is the same as bug 6837?
Comment 9 Owen Leonard 2016-01-15 14:30:06 UTC
What is the status of this bug since Bug 5786 has moved the AllowOnShelfHolds system preferences to circulation and fine rules?

How does this relate to Bug 15534?
Comment 10 Katrin Fischer 2016-02-28 20:20:15 UTC

*** This bug has been marked as a duplicate of bug 15534 ***