Summary: | cancelling hold from holds awaiting pickup does not trigger transit | ||
---|---|---|---|
Product: | Koha | Reporter: | Nicole C. Engard <nengard> |
Component: | Hold requests | Assignee: | Srdjan Jankovic <srdjan> |
Status: | CLOSED FIXED | QA Contact: | Bugs List <koha-bugs> |
Severity: | major | ||
Priority: | P5 - low | CC: | gmcharlt, michael.hafen, smoreland, srdjan, wizzyrea |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | Sponsored | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Attachments: |
patch
patch |
Description
Nicole C. Engard
2011-06-09 17:00:45 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? 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. |