Bug 4239 - Allow holds on multiple items of selected titles
Summary: Allow holds on multiple items of selected titles
Status: RESOLVED DUPLICATE of bug 7710
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: 3.4
Hardware: PC All
: PATCH-Sent (DO NOT USE) enhancement with 10 votes (vote)
Assignee: Jane Wagner
QA Contact: Bugs List
URL:
Keywords:
Depends on: 4806
Blocks: 2532
  Show dependency treegraph
 
Reported: 2010-02-22 07:52 UTC by Jane Wagner
Modified: 2013-10-20 18:13 UTC (History)
10 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
Screen shot of syspref setup (22.69 KB, image/jpeg)
2010-02-22 19:52 UTC, Chris Cormack
Details
enable multiple hold working with item-level_itype=ON (2.59 KB, patch)
2010-04-24 21:42 UTC, Chris Cormack
Details | Diff | Splinter Review

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


---- Reported by jwagner@ptfs.com 2010-02-22 19:52:17 ----

Created an attachment
Screen shot of syspref setup

Sponsored by Middletown Township Public Library, Middletown, NJ, USA.

The library wants to allow users to place holds on more than one item belonging to a particular title in certain cases, such as a serial title or a multi-volume DVD.  This enhancement creates a syspref (AllowMultipleHoldsPerBib) which takes as input a string (in quotes) of item type codes.  Any item type in this list will allow multiple items to be placed on hold.  There is no difference in the hold placement procedure itself, but the system will not bring up the "you already have a hold on this item" block.



---- Additional Comments From dbavousett@ptfs.com 2010-04-21 14:24:36 ----

Branch http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4239 on git://github.com/ptfs/Koha-PTFS.git has most everything you should need to allow multiple holds per bib on selected item type values.  Mandatory SQL is in the commit message; we have this running against an older version of HEAD; I did a quick update to HEAD, but C4::Reserves has moved a bit since then, so there may be a few tweaks needed to get this feature fully happy.



---- Additional Comments From paul.poulain@biblibre.com 2010-04-24 20:21:53 ----

there is a small bug in the SQL description : 
it's written :
    ALTER TABLE `old reserves` ADD COLUMN `reservenumber` int(11) NOT NULL;
where the correct SQL is :
    ALTER TABLE `old_reserves` ADD COLUMN `reservenumber` int(11) NOT NULL;
("old_reserves" vs "old reserves")



---- Additional Comments From paul.poulain@biblibre.com 2010-04-24 20:54:35 ----

a lot of warn (without $DEBUG) are remaining on the patch



---- Additional Comments From paul.poulain@biblibre.com 2010-04-24 21:07:17 ----

seems the patch work only is you have item-level-itype set to NO :
    if ( $biblioLoopIter{already_reserved} && !CanHoldMultipleItems($biblioLoopIter{itemtype}) ) {

(line 461 of opac-reserves.pl)
biblioLoopIter checks only the biblio level if I read correctly




---- Additional Comments From paul.poulain@biblibre.com 2010-04-24 21:42:31 ----

Created an attachment
enable multiple hold working with item-level_itype=ON





---- Additional Comments From jwagner@ptfs.com 2010-05-12 13:55:55 ----

The fix for this bug (in ptfs-harley) can also be pulled from the public git repository at http://github.com/Koha-PTFS, branch http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4239




--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:24 UTC  ---

This bug was previously known as _bug_ 4239 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4239
Imported an attachment (id=1927)
Imported an attachment (id=1928)

Unknown operating system Windows 2000. Setting to default OS "All".
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 jwagner@ptfs.com.
The original assignee of this bug does not have
   an account here. Reassigning to the default assignee
   for the component, gmcharlt@gmail.com.
   Previous assignee was kohaprogrammers@ptfs.com.
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
Bug reassigned, setting status to "NEW".
   Previous status was "ASSIGNED".
CC member jwagner@ptfs.com does not have an account here
The original submitter of attachment 1927 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 1928 [details] [review] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.

Comment 1 Nicole C. Engard 2010-06-04 14:08:39 UTC
Can I ask why this is a preference? and not in the circ rules or item types admin area? It seems like a very confusing looking preference.

This question comes from some talk on IRC today - if you're curious why I'm commenting now.
Comment 2 Ian Walls 2011-11-19 15:14:12 UTC
The first thing required to get this to work is a primary key on the reserves table!  Right now, borrowernumber + biblionumber are being used as the match point, which precludes multiple holds on a single title.

The patch here is insufficient by itself, and references a system preference not already in Koha.  Marking as obsolete.

The need for some kind of restriction mechanism still exists; not all libraries will want patrons to be able to place multiple holds on a material; this could lead to gaming the system by placing holds on every available copy of a popular book, for example.  I think a control mechanism that looks at the items.enumchron field for distinct values would be a way to go; this would let different vol/issue items, for example, take in multiple holds, but equivalent copies could still be restricted (unless they were explicitly given distinct enumchron values)
Comment 3 Jared Camins-Esakov 2012-02-13 13:21:33 UTC
The Harley integration project has been stalled for some time.
Comment 4 Chris Cormack 2013-10-20 18:13:28 UTC

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