SIP2 doesn't report hold queue information

[Thomas Berezansky]

I assume this is, in part, because we don't have a real hold queue.

But, some vendors want to know if the item is in transit to fill a hold. Thus, the branch below basically fills the "hold queue" with the captured hold's ID. This should result in a 1 in the appropriate field when an item is captured for a hold, as SIPServer already populates the field in question....assuming that we have returned anything of use, anyway.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/sip2_hold_queue

[Mike Rylander (mrylander)]

This is, I suspect, for use with AMH devices and such? Assuming so, I think it would be useful to know what products has it been tested with so far, as returning this could conceivably change behavior for some existing setups. (Which also, of course, implies testing this with other existing setups to make sure it causes no adverse reactions... but that's not on you, obviously, Thomas.)

[Jason Stephenson (jstephenson)]

Actually, it is for a "sort-to-light" system used by our statewide delivery company. They scan barcodes and do item information look ups via SIP2 to find out where copies should go.

They promised their client (the state) that they could tell if copies were being sent to fill holds or simply returned to their owning libraries and could do some sorting based on that. This promise was apparently based on features of some other ILS' implementation of SIP2 that returns a hold count in the field in question.

Looks like SIPServer was mostly setup to do this. Evergreen just needed the nudge to return the data to SIPServer.

[Ben Shum (bshum)]

Picked to master!