Bug 16260 - Have AllowHoldsOnPatronsPossessions check for multiple holds allowed on a record
Summary: Have AllowHoldsOnPatronsPossessions check for multiple holds allowed on a record
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 9206 14695
Blocks:
  Show dependency treegraph
 
Reported: 2016-04-14 15:22 UTC by Marjorie Barry-Vila
Modified: 2023-10-08 21:15 UTC (History)
8 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 16260: Remove CheckIfIssuedToPatron (1.36 KB, patch)
2023-10-04 08:48 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 16260: Adjust logic of AllowHoldsOnPatronsPossessions (6.65 KB, patch)
2023-10-04 08:48 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Marjorie Barry-Vila 2016-04-14 15:22:57 UTC
Hi,

System preference AllowHoldsOnPatronsPossessions is too restrictive.

Test plan:
-AllowHoldsOnPatronsPossessions : Don't allow


-notice with 2 items (X and Y)

-one of items is check-out by borrower A (item X)

-other items is check-out by borrower B (item Y)

If Borrower A wants to hold item Y, he can not because of the system preference.

If system preference is Allow, Borrower A can hold item Y but he can hold item X too, and we don't want that he can.


Is there something I do not understand in the configuration ?

Regards,
Marjorie
Comment 1 Christopher Brannon 2018-12-01 21:21:35 UTC
I agree that this AllowHoldsOnPatronsPossessions is a problem.

Currently, we have certain records that we allow mulitple holds on.  The patron cannot place a hold on one of these items if they have something on that record checkout out and AllowHoldsOnPatronsPossessions is set to Don't allow.  This preference needs to take into account circ rules that allow multiple holds on a record.
Comment 2 Jonathan Druart 2019-06-06 20:42:20 UTC
I'd say that code related to AllowHoldsOnPatronsPossessions (from reserve/request.pl and opac/opac-reserve.pl) must be moved to C4::Reserves::CanBookBeReserved
Comment 3 Azucena Aguayo 2020-02-26 00:09:24 UTC
Our library just turned this feature ON. 

Most of our titles have a single copy and this feature works perfectly for that. However, when dealing with volumes the system preference falls short.

Example:
Title X has v1, v2, v3
Patron A checked out v1
Patron B checked out v2

Patron A wants v2 when it gets back.
Patron A cannot place hold on v2.
Patron A must return v1 before placing hold on v2


Not ideal for all cases, but it would help if the preference could restrict on number of items attached to a single bib.

Example:
Title X with 1 copy = holds not allowed on possession
Title Y with 2+ copies =
     if all copies cko to borrower then no holds
     else if borrower cko title copies < max title copies then holds allowed
Comment 4 Christopher Brannon 2023-10-03 18:46:01 UTC
(In reply to Christopher Brannon from comment #1)
> I agree that this AllowHoldsOnPatronsPossessions is a problem.
> 
> Currently, we have certain records that we allow mulitple holds on.  The
> patron cannot place a hold on one of these items if they have something on
> that record checkout out and AllowHoldsOnPatronsPossessions is set to Don't
> allow.  This preference needs to take into account circ rules that allow
> multiple holds on a record.

Would really like to see this oversight or conflict in logic addressed.  It is an ongoing issue.
Comment 5 Jonathan Druart 2023-10-04 08:44:26 UTC
(In reply to Jonathan Druart from comment #2)
> I'd say that code related to AllowHoldsOnPatronsPossessions (from
> reserve/request.pl and opac/opac-reserve.pl) must be moved to
> C4::Reserves::CanBookBeReserved

Done on bug 22806.
Comment 6 Jonathan Druart 2023-10-04 08:48:27 UTC
Created attachment 156518 [details] [review]
Bug 16260: Remove CheckIfIssuedToPatron
Comment 7 Jonathan Druart 2023-10-04 08:48:29 UTC
Created attachment 156519 [details] [review]
Bug 16260: Adjust logic of AllowHoldsOnPatronsPossessions
Comment 8 Jonathan Druart 2023-10-04 08:49:51 UTC
I think this patch is doing what you are expecting, but I am not sure this is a change everybody will agreed on.

The syspref's description is clear enough: "Allow/Do not allow a patron to place a hold on a record where the patron already has one or more items attached to that record checked out."

Patch for discussion.
Comment 9 Christopher Brannon 2023-10-04 18:59:10 UTC
So, my concern is, we don't want to just turn this system preference on for everything, but we have had to, because we have a mixed bag of records.  Usually, a record has multiple copies of the same thing.  We don't need one person monopolizing those items.

However, we also have records that contain many different things.  Like serials.  Every copy for a title is under one bib.  We do want patrons to have the liberty of placing holds on other items while they have an issue from that bib checked out.

We currently have to have this preference on.

The original function works as it should.  We also use the Holds per record rule set to 1 for most items where we don't want people to place a second hold.  But that does not account for an item that a patron has checked out.  They can still place a hold.

What needs to happen is that we need to define if this Holds per record rule includes current issues or not.  I think that is the key element that is being overlooked here.
Comment 10 Katrin Fischer 2023-10-08 21:15:14 UTC
This behaviour has remained unchanged since introduction of the feature, I think  at this point any change is more an enhancement than a major bug. 

The feature pre-dates the ability to allow multiple holds on a record and it's worth re-thinking this situation and also the item level holds one.

There are several things at play here, but it seems to me like the real question is if the items are identical or not. That's not easy to tell. One solution could be the hold level:

* If item level holds are allowed, don't allow a hold on the item already checked out to me, but on others.
* If no item level holds are allowed, don't allow a hold if any item is already checked out to me.

We could use number of holds allowed... but it makes things a bit more complicated for what Christopher said: with a setting of 1 hold allowed, should the already checked out item count? We'd mix number of allowed holds with the checkouts. That does not feel quite right. 

I think the question here is not if the max allowed holds is reached, but if you have the item in question at home already or not.