Bug 3270 - Cancelling a hold request after transfer initiated orphans item
: Cancelling a hold request after transfer initiated orphans item
Status: NEW
Product: Koha
Circulation
: HEAD
: PC All
: P5 major (vote)
Assigned To: Galen Charlton
:
:
:
:
  Show dependency treegraph
 
Reported: 2009-05-29 12:55 UTC by Chris Cormack
Modified: 2010-02-23 01:30 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---


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