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
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?
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.
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
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?
Created attachment 6504 [details] [review] patch
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.
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".
Created attachment 6899 [details] [review] patch
This new patch applies for me - will test.
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
The patch I provided is actually wrong. I think that your problem was actually resolved in master. Can you please confirm that and cancel.
This appears to have been fixed in master.