---- 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.
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.
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)
The Harley integration project has been stalled for some time.
*** This bug has been marked as a duplicate of bug 7710 ***