Bug 6489 - cancelling hold from holds awaiting pickup does not trigger transit
Summary: cancelling hold from holds awaiting pickup does not trigger transit
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: master
Hardware: All All
: P5 - low major (vote)
Assignee: Srdjan Jankovic
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-09 17:00 UTC by Nicole C. Engard
Modified: 2014-05-26 21:04 UTC (History)
6 users (show)

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


Attachments
patch (2.18 KB, patch)
2011-12-02 04:06 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (2.19 KB, patch)
2011-12-21 08:00 UTC, Srdjan Jankovic
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2011-06-09 17:00:45 UTC
When an expired hold is canceled using this report, the status of the item
changes from "Waiting for Patron A" to "Available."  The status does not
indicate that a transfer has been triggered.  Unlike before the recent upgrade,
the current location changes to the owning branch rather than erroneously
updating the the holding branch.

Here is my testing. http://screencast.com/t/aekZRW6Hh
Comment 1 Srdjan Jankovic 2011-09-19 04:59:58 UTC
I have tried this on the master branch and it is reporting "In transit from X, to Y, since dd/mm/yyyy

Which version are you running please?
Comment 2 Liz Rea 2011-09-29 14:47:23 UTC
Srdjan, 
I will re-test this today on Master.

I'm sure that this was on a version somewhat back from the bleeding edge of master.
Comment 3 Sharon Moreland 2011-11-03 17:07:55 UTC
This bug seems to be fixed.  The transit home for re-shelving occurs and if another hold is found, the 'submit query' button appears.  The process is clunky and could use improvement, such as transfer and "confirm hold, print slip and transfer" prompts.  

My testing: http://screencast.com/t/lneRY70yW
Comment 4 Sharon Moreland 2011-11-03 17:13:05 UTC
I took this one step further - I scanned in the barcode of an item put into transit to fill a hold using the Holds Awaiting Pick-up reports "submit query" button.  You get 2 transfer prompts, but confirming the hold (the bottom prompt) acts as expected.

Silent video: http://screencast.com/t/dKXmrULwM

I suppose making this report provide the same dialogue boxes and such will need to be an enhancement request?
Comment 5 Srdjan Jankovic 2011-12-02 04:06:27 UTC Comment hidden (obsolete)
Comment 6 Michael Hafen 2011-12-02 18:36:02 UTC
I looked at this patch and it raises a question for me, which is how it interacts with the IndependantBranches setting.  It will depend on how well CheckReserves handles IndependantBranches, which as I recall isn't good.  Maybe that has changed in master though.
Comment 7 Katrin Fischer 2011-12-21 07:36:07 UTC
Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all y
Applying: bug_6489: Do not raise WrongTransfer if it is transrerring to reserve branch
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging C4/Circulation.pm
CONFLICT (content): Merge conflict in C4/Circulation.pm
Failed to merge in the changes.
Patch failed at 0001 bug_6489: Do not raise WrongTransfer if it is transrerring to reserve branch
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
Comment 8 Srdjan Jankovic 2011-12-21 08:00:20 UTC
Created attachment 6899 [details] [review]
patch
Comment 9 Liz Rea 2011-12-21 20:03:25 UTC
This new patch applies for me - will test.
Comment 10 Sharon Moreland 2012-01-04 18:03:01 UTC
The Holds Awaiting Pickup report buttons now works - good news (see testing video below).

However, behavior related to misrouted holds (or how the checkin box works when you scan an item that is in transit or on hold and in transit at the wrong library) is now different from what we have version 3.06.00.000 (our production server). 

Video of canceling a hold from the report and double-scanning it - http://screencast.com/t/zPAeQDHyE

Video of misrouting an item on hold - this happens quite often in our large consortium with 4 different libraries starting with 'O'... http://screencast.com/t/VaRZTy8vmFLl

Video of misrouting an item on hold in 3.06.00.000, so you can see the difference.  Could be related to Bug 6226 or not.  http://screencast.com/t/KTYCUWrvCvb

Hope that all makes sense...
Sharon
Comment 11 Srdjan Jankovic 2012-01-05 03:44:17 UTC
The patch I provided is actually wrong. I think that your problem was actually resolved in master. Can you please confirm that and cancel.
Comment 12 Owen Leonard 2013-08-08 19:51:50 UTC
This appears to have been fixed in master.