Bug 3270 - Cancelling a hold request after transfer initiated orphans item
Summary: Cancelling a hold request after transfer initiated orphans item
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: 3.4
Hardware: PC All
: PATCH-Sent (DO NOT USE) major (vote)
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-29 12:55 UTC by Chris Cormack
Modified: 2013-12-05 20:04 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
Proposed patch (1.66 KB, patch)
2011-03-30 16:46 UTC, Liz Rea
Details | Diff | Splinter Review

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:32 UTC


---- Reported by rch@liblime.com 2009-05-29 00:55:07 ----

Koha fails to direct a user to return an item to its home library if the hold request that initiated a transfer is canceled before it is filled.  Checking that item in at its holding location simply reports 'not checked out'.
Furthermore, if this item is checked in at any other location, no 'forced transfer' entry is created in branchtransfers.
This is with HomeOrHoldingBranch set to 'holdingbranch'.
If HomeOrHoldingBranch is set to 'homebranch', then the checkin is disallowed and the user is directed to return the item to its home library ( but no transfer is initiated, no slip to print ).

This exposes a needed enhancement, allowing certain items to float between locations, which is certainly a desired feature.  However, I think the default behavior should be to prompt the user to return the item to its home location if homebranch != holdingbranch and no outstanding holds exist.

Steps to recreate:
  1 place a hold on an item, with pickup library != item home library.
  2 check in the item, initiating transfer to pickup library
  3 cancel the hold
  4 check in item at pickup library.  Wonder what you should do.



---- Additional Comments From joe.atzberger@liblime.com 2009-06-02 20:01:15 ----

To clarify: this really doesn't depend on a cancelled hold.  The functionality desired would be the same if the book just magically showed up at the 2nd branch.



---- Additional Comments From smoreland@nekls.org 2009-08-18 19:37:11 ----

We have a experienced a behavior that may be related to this bug - We are unable to update the current location of an item by checking it in at the home branch.  This item was 'orphaned' when a hold was canceled while the item was in transit between libraries.

The item is owned by Library A and sent to Library B to fill a hold.  The item was scanned and transferred to Library B for a staff member.  We are unclear if the item was ever checked in at Library B, thereby 'completing' the transit (I guess not - I could see where the item was just handed to the staff person w/o being scanned, but I can't confirm this suspicion).  I believe it was not checked in because when I first saw this item, the status said "Item in transit from Library A to Library B since 8/12/2009" (no patron & no hold because it had already been canceled by the staff member when she decided she didn't want the item - she did not check it out to herself). 

I changed my 'set' library from Library A to Library B and scanned the item.  This updated the status from 'In Transit' to 'Available.'  I scanned the item again to see if I would be prompted to return the item to the home branch (Library A), but no prompt was shown.  I changed the 'set' library to Library A and scanned the item.  The current location did NOT update from Library B to Library A.  I tried repeatedly with no luck.



---- Additional Comments From smoreland@nekls.org 2010-02-22 22:58:20 ----

http://screencast.com/t/OWE5ZWUxNW

This is a screencast, with explanation of how this bug still appears in 3.2.  



---- Additional Comments From oleonard@myacpl.org 2010-02-23 01:30:55 ----

See also http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4040. These all seem to fall under what could be an omnibus "transfers are fubared" bug.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:08 UTC  ---

This bug was previously known as _bug_ 3270 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3270
This bug blocked bug(s) 2941.

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 rch@liblime.com.
CC member dianajweaver@gmail.com does not have an account here
CC member joe.atzberger@liblime.com does not have an account here

Comment 1 Sharon Moreland 2011-02-25 15:27:06 UTC
Just tested this today and it is still active.  A video: http://screencast.com/t/HN052lJGZ
Comment 2 Mickey Coalwell 2011-03-08 03:00:58 UTC
Today we saw a variation on the "Cancel Hold in Transit" bug. Call it the "Cancel Hold That's Waiting" bug. Situation:
> I just deleted a hold for a patron who no longer needed the item. The book is owned by another library. The hold was deleted from the patron account, and I then scanned the item to get the prompt to return it. Instead, the "not checked out" box appeared, without a prompt to return the item. The Current Location updated, but the transfer message did not occur.
Comment 3 Liz Rea 2011-03-30 16:46:09 UTC
Created attachment 3538 [details] [review]
Proposed patch

from druthb
Comment 4 Chris Cormack 2011-03-31 08:23:33 UTC
Patch pushed, please test
Comment 5 Jared Camins-Esakov 2012-12-31 00:10:55 UTC
There have been no further reports of problems so I am marking this bug resolved.