Bug 3288 - No transit prompt and slip when waiting hold is canceled
Summary: No transit prompt and slip when waiting hold is canceled
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Galen Charlton
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-03 03:48 UTC by Mickey Coalwell
Modified: 2023-10-07 20:21 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

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


---- 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

Comment 1 Marc Véron 2016-02-10 17:11:57 UTC
Still valid?
Comment 2 Katrin Fischer 2023-10-07 20:21:10 UTC
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.