I think you should be able to handle this entirely within the ILS driver, though doing so may not be the most efficient option.  The basic idea is anywhere that a hold requires an item ID, the driver can always call $this->getHolding() using the bib ID and then extract an item ID from that response.


Two possible approaches:


1.)    The hacky way – if you look at HoldLogicTitle::driverHold(), you will see that VuFind asks the driver if a given hold is valid by calling the driver’s checkRequestIsValid() method.  Right now, the Unicorn driver doesn’t define this method, which causes VuFind to assume that everything is valid all of the time.  However, if you wanted to be clever, you could define this method and make sure that the second parameter ($data) is passed by reference rather than by value.  That way, you could inject values (like item IDs) into the array inside the checkRequestIsValid() method, and these injected values would pass on down to the URL generated by HoldLogicTitle::_getHoldDetails().  Admittedly, I don’t actually like this solution – it results in potentially confusing code since the source of the modification to the $data array is decidedly non-obvious.  But it might be the easiest way to modify the hold URL without touching core VuFind code.

2.)    The more logical way – wait until Unicorn::placeHold is called, check the value of $holdDetails[‘level’], and load an item ID on the fly with $this->getHolding() as needed.  You can always fail with an error if no item ID can be found.  I think I like this solution the best: it avoids touching core code, it’s relatively easy to understand, and it avoids doing extra lookups until you know for sure that the data is actually needed.  (A minor delay during a “place hold” process is unlikely to upset a user… but if displaying holdings becomes slow due to unnecessary up-front lookups, more people will be adversely affected).


Does that make sense, or am I missing something important?


Also, once you get this all sorted out, would you be willing to share a patch?




From: Chanel Wheeler [mailto:Chanel.Wheeler@co.yavapai.az.us]
Sent: Tuesday, May 29, 2012 2:07 PM
To: vufind-tech (vufind-tech@lists.sourceforge.net)
Subject: [VuFind-Tech] title level hold needs item_id


Hopefully I can get through this without my brain exploding….


I’m working on customizing VuFind 1.3 to meet our consortial needs. One of those needs is that monographs have a title-level hold but serials and volume-based works have copy-level holds. I’ve integrated the 1.4 patch from VUFIND-507 in as much as I can (we use Symphony, not Voyager). It assumes you can place a title-level hold with a catkey. Here’s the silly clincher: Symphony requires an item-level ID to do a title hold (please join me in beating SirsiDynix senseless).


I’ve worked out what I need to do to solve my problem but I’m not sure where the best place is to do it (or if there is a suitable place at all). My preferred approach is to structure the title-level hold URL so that it has an item_id in the parameters. This puts me at odds with the private function _getHoldDetails which assumes that the ID used in the URL for the record will be the same as used in the hold parameters. I really don’t want to hack core code if I can help it.


The other approach I see is to leave the title level hold URL as is and then add the item_id in an extension to Hold.php  (I’m assuming this is possible – my brain is so worn out from working through all the code so far that I haven’t gone through Hold.php in detail).


Is there a better approach I haven’t thought of? If not, would it be possible in Hold.php to process the holdings to find a valid item_id (some individual holdings may not be holdable but a title-level hold is still valid because other holdings on the record are) and then modify what gets sent to the driver so that it contains that item_id?






Chanel Wheeler

Library Network Programmer/Analyst

Yavapai Library Network

1015 Fair Street, #326

Prescott, AZ  86305


Phone: (928) 442-5741