Bug 2532 - Patron-requested holds limited to one item per bib.
Summary: Patron-requested holds limited to one item per bib.
Status: RESOLVED DUPLICATE of bug 14695
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Galen Charlton
QA Contact: Bugs List
URL:
Keywords:
Depends on: 4239
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-18 10:24 UTC by Chris Cormack
Modified: 2016-08-10 17:37 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

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 00:52:16 UTC


---- Reported by rch@liblime.com 2008-08-18 22:24:12 ----

The current holds implementation limits a hold to be either title-level or item-level, and only one outstanding hold may be placed at a time.  This is a significant shortcoming, especially for serial records, where a patron may wish to request several issues.
There should be some way to distinguish whether all item records attached to a bib record are equivalent in the sense of fulfilling a hold request.  I feel at this stage that using the biblio.serial flag should be sufficient for this.  ( However, note that the existence of a series title can trigger the serial flag.  I think that is a behavior added by BibLibre, and should be addressed).
If there is such a flag, then we can allow multiple item-level requests on a single bib, and, on fulfillment, cancel all other hold requests if items are determined to be equivalent.

There is some code for this tucked away in the dev_week branch, though I imagine at this point the holds code will need to be refactored such that that code is irrelevant.

In short, this enhancement request is for allowance of multiple concurrent item-level, but a precursor I think is the stated interpretation of the biblio.serial flag as indicating that multiple concurrent item-level holds are _not_ equivalent, where in all other cases they are.



---- Additional Comments From oleonard@myacpl.org 2008-08-19 05:50:08 ----

There are other situations besides serials where multiple items might be reserved: multi-volume sets like encyclopedias or multi-part video sets (NPL's bugbear: http://search.athenscounty.lib.oh.us/cgi-bin/koha/opac-detail.pl?bib=93738). It is also useful for staff to be able to reserve multiple items. Catalogers may need to retrieve all copies of a particular item for relabeling. Staff may wish to reserve multiple copies of a book for use in a book discussion group. It would be great to give staff users that option.



---- Additional Comments From jwagner@ptfs.com 2009-05-29 11:41:08 ----

Is this covered by the patch being sent for http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3093?



---- Additional Comments From kdr@ckls.org 2009-06-25 22:09:23 ----

In addition to the points made by Owen, both patrons and staff can not tell which barcode is a certain volume without jumping back and forth to the detail page or writing down the appropriate barcodes.

This is not at all user-friendly. Can another column be added derived from the 952h (Serial Enumeration / chronology)and displayed on the hold page in both the OPAC and staff? I believe this goes hand in hand with the possibility of placing holds on more than one monographic volume at a time (which is needed!)



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:52 UTC  ---

This bug was previously known as _bug_ 2532 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2532

Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here: chris@bigballofwax.co.nz.
   Previous reporter was rch@liblime.com.
CC member adrea@moablibrary.org does not have an account here
CC member dianajweaver@gmail.com does not have an account here
CC member jwagner@ptfs.com does not have an account here
CC member kdr@ckls.org does not have an account here

Comment 1 Katrin Fischer 2011-04-25 13:53:04 UTC
>This is not at all user-friendly. Can another column be added derived from the
>952h (Serial Enumeration / chronology)and displayed on the hold page in both
>the OPAC and staff?

This is the case since 3.2

But there is no functionality yet to allow multiple holds on one record.
Comment 2 Owen Leonard 2013-10-22 00:22:34 UTC
This bug is so old that I wonder what the original reasoning behind it was. I assume that it was intended to prevent users from gaming the holds system by placing holds on multiple copies at multiple locations in an attempt to improve chances of a fast delivery (perhaps branch A will get it first for me, perhaps branch B).

Does anyone know of a different reason?
Comment 3 Bob Birchall 2013-10-22 01:59:43 UTC
I am marking this 'In discussion.'  It is hardly new.  :)

At least one library I know of wants this enhancement.  Owen has explained that there is concern the feature could allow gaming of the holds queue. Maybe a way to control that could be discerned?

Should the feature be developed and a 'wait and see' approach adopted to the gaming risk?
Comment 4 Katrin Fischer 2016-08-10 06:55:27 UTC
Hm, this reads a bit like a duplicate to bug 14695 - can someone confirm?
Comment 5 Eric Phetteplace 2016-08-10 16:34:58 UTC
It looks like a duplicate to me, too.
Comment 6 Katrin Fischer 2016-08-10 17:37:22 UTC

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