---- Reported by mcoalwell@nekls.org 2009-06-03 15:48:34 ---- Mickey says: Canceling the 'hold over' from waitingreserves.pl should trigger a transit prompt, instructing the staff person to send the item on to the hold library, if a hold exists on the item. This doesn't happen. Nothing happens when the 'hold over' is canceled. A staff person, seeing the information displayed in the ACTION column, would naturally assume that the item is to return to its home library. So, regardless of whether a hold exists, the 'hold over' canceled item is being returned home. We have found that a hold transit prompt will trigger if the canceled hold item is checked in after it is canceled. But this is a two-step process that we have not trained any of our libraries to perform. We are seeing lots of problems associated with this, since many hold items are being sent back to their home locations, instead of their next hold location Galen says: The script does appear to have nascent but incomplete functionality to generate a transfer message. I recommend filing a bug for this one. ---- Additional Comments From smoreland@nekls.org 2009-08-12 21:39:35 ---- I would suggest eliminating the second button option "Cancel and Return to: HOMEBRANCH" and instead have the Cancel Hold button do a number of tasks: Cancel the hold, so the item can be reshelved back into the collection (assumes items.homebranch = items.holdingbranch). Cancel the hold and present a message to the staff to transit the item back to the item's homebranch (items.homebranch != items.holdingbranch). Cancel the hold and present the dialogue box to confirm and transfer, if necessary, the item to fill the next hold in the queue. Or, have 3 buttons: "cancel hold", "cancel and return to: HOMEBRANCH", and "cancel and fill hold at: (this is the sticky part, because you need to know where to send the item and patron information)" Just my $.02... ---- Additional Comments From smoreland@nekls.org 2009-08-24 14:34:17 ---- While the wording of the buttons at koha/circ/waitingreserves.pl needs to be changed, the functionality appears to work as expected. The wording of the transit slip created 'on the fly' when an item has a 2nd or 3rd hold on it is very clunky. "Hold find for" should be "Hold found for," for example. Ideally, the transit slip produced when using waitingreserves.pl to cancel holds should be the same dialogue box generated by the checkin function (with the options to confirm, print confirm or ignore). --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:08 UTC --- This bug was previously known as _bug_ 3288 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3288 Actual time not defined. Setting to 0.0
Still valid?
This is still valid, we do create a transfer, but we don't trigger a message to the staff or allow for printing a transport slip.