UPDATE: Some of the behaviours mentioned in my first comment are now irrelevant. It seems that there was a hidden default circulation rule that was affecting the returns script in regards to my transfer branch. Following an ordinary workflow, the hold is found by the transfer branch. However, if you check in at the from branch (even though you should've probably dumped the book in the mail) and choose Option 1 (as outlined in my first comment) the status of the item will remain "in transit" even when it's actually waiting for the patron... It might be an abnormal workflow, but it still seems to be a bug to me. David, Perhaps this will help and add to the case. I've noted a couple scenarios related to this issue. I think it is a bug, and needs to be addressed. I am copying this from reports I made to our support team, so sorry if some of the info is redundant. Scenario 1: Item is placed on hold to be picked up at location A. Item is checked in and confirmed, and now shows it is on it's way to location A. Before it is sent out to location A, we discover that the patron wants the hold picked up at location B. Hold is changed from In Transit to a priority level 1. Pickup location is changed to location B. Item is checked in to trigger hold and transfer. Now TWO messages appear. One for the original transfer, and one for the new transfer. Observation: Changing the hold status from In Transit to a new status, like a priority level, doesn't completely clean up the In Transit status. If the item went out the door and ended up at location A after the change, they only see one message, which is to send it on to location B. However, if the item doesn't go out the door to location A, and is checked in after the change, we see a transfer message for both location A and B. I can go ahead and fulfill the transfer for location B, just ignoring the first message. I can also cancel the transfer on the first message, and then check in the item again, and only get the one message to transfer to location B. Ideally, if the In Transit status is changed, Koha should clean it up completely (essentially doing the cancel of the first transfer I could do if I see the two messages). Scenario 2: Item is placed on hold to be picked up at location A. Item is checked in and confirmed, and now shows it is on it's way to location A. Before it is sent out to location A, we discover that the patron wants to cancel the hold, or has already cancelled it. We cancel it if the patron is telling us to. This is not enough. Even with the hold cancelled, the item still thinks it needs to go to location A. Item is checked in. Now TWO messages appear. One for the transfer, and one shows a local use window. Observation: If we do nothing, the transfer is still stuck to the item, no matter how many times we check it in. You either have to make sure you check it in, and cancel the transfer, or check it in, send it to location A and then then send it back after they check it in. It seems to me that the transfer should have been cancelled with the hold. Koha seems to be treating holds and transfers independently. This creates a lot of confusion and potential problems. Hope this helps. Christopher Brannon Holds and transfers are independent, by design. Holds are not the only reason you might like to transfer items between branches or libraries. So I would caution whoever works on this bug not to break a feature in use, when fixing this. Created attachment 13534 [details] [review] Bug 8451 - Confusing and problematic double prompt for processing transfers This patch will cause changing the priority of a reserve from 'in transit' to a priority number to delete the transfer associated with it, if there is one. This seems to be working, assuming the test plan is: 1. Place a hold on an item for delivery to another branch. 2. Check in the item and confirm the transfer. 3. Edit the hold, changing the status from in-transit to a priority number. 4. Check in the item again. Before the patch I would see two prompts at step 4. After the patch I see one. I think, however, that this needs a follow-up for cases when instead of modifying the status in step 3 the hold is deleted. Created attachment 14275 [details] [review] [SIGNED-OFF] Bug 8451 - Confusing and problematic double prompt for processing transfers This patch will cause changing the priority of a reserve from 'in transit' to a priority number to delete the transfer associated with it, if there is one. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Tested with this plan: 1. Place a hold on an item for delivery to another branch. 2. Check in the item and confirm the transfer. 3. Edit the hold, changing the status from in-transit to a priority number. 4. Check in the item again. Before the patch I would see two prompts at step 4. After the patch I see one. Hi Kyle, Rather than adding a new parameter to the ModReserve routine, can we replace the biblionumber and borrower parameters with the new reserve_id you introduced? I have reservations about this patch which I cannot fully articulate, but it has to do with the behaviour of transfers and 9322 - I think it may be dangerous to fix this, in this way, while 9322 is still an issue. The only real solution I see to this particular problem, is finding a way to link a reserve specifically to it's associated transfer, and make it delete only transfers associated with the reserve that has been re-ordered/deleted/whatever and leave the explicit transfers (done through branchtransfers.pl) alone. The reason for this is that you could have a legitimate situation where an item is supposed to be going two places at the same time, or at least Koha is being told to send something to two places at the same time. Koha can probably not ever be smart enough to know which to prefer, an explicit transfer or a reserve generated transfer, which is why there are two prompts. The messages are certainly confusing - this bug has been a problem for years (I'm thinking specifically of issues reported by NEKLS, because that is where I have my experience with dual prompts). Certainly this is one way to fix the issue at hand in this bug, but I also think we need to think carefully about the design of explicit transfers and reserve generated transfers. Currently Koha doesn't differentiate between them, and bug 9322 is certainly muddying the water as to "when transfers are completed in *any* situation." Sorry to be so long winded, but I honestly think we really need to think about how to fix this in a way that makes sense for all transfers and not just reserve transfers. And more importantly, we need to think about how we can present the information that there are two kinds of transfers for an item, if that is the case, in a way that is not confusing to library staff. LR QA: Looking at this one now.. QA Comment: This is a hard one. Also taking into account the comments of Liz and Jonathan. I do appreciate your finding a solution in this minefield :) When taking some distance from Koha and just looking at the code, the introduction of the reserve id parameter in ModReserve seems not to be a good idea. It is somewhat 'unusual' way of resolving a problem. (Please note that I understand that we are editing not-so-ideal code already..) It will not make the code more readable/maintainable(..) When going back to Koha, I also think that we should resolve the problem at another place. That is the checkin should not display two prompts (probably one adjusted prompt for this situation). When the book is checked in at the transfer branch, the transfer should be marked as arrived and at the same time the transit hold should become a waiting hold. Actually, AddReturn calls ModReserveStatus but it will update a book with priority 0 only for found="" and not for found=T. Could we resolve it there? About Liz' comment: If we want to know where the transfer was generated, we should probably add some additional field to branchtransfers. At this moment we just do not know how it was generated. So my (somewhat intuitive) recommendation would be not to push this patch in this state. I just 'arbitrarily' picked Failed QA for now. But feel free to put it in Discussion and raise a discussion on the dev list. I will send a short mail to other QA team members. I know this is an old bug, but I just discovered the original bug that David reported on the Holds Waiting Pickup report on our system, running 3.14.8. We're moving to 3.16.4 this weekend, and I bet it will still be there; we continue to have the holds cancel buttons on this report hidden using JQuery. The bug that Christopher Brannon reported later is a separate issue -- but I think that's what the patch was written for that Failed QA more than a year ago. What's the best way to get the Holds Waiting Pickup bug moving along again? A separate bug? Or something else? Bug 17101 as well raises the question about multiple prompts while checking in. I think it is an architectural question that needs a separate bug. Setting to "In Discussion" (See comment #10) Not know this was being addressed, I tried my hand at it in 18503. I think unless someone can clearly present a scenario that would involve a hold an separate transfer in which both prompts need to be displayed, I have a hard time justifying keeping it in this state. If there is a legitimate need, then lets spell it out and make it work better for that scenario. Can someone come up with a scenario in which both are needed? This has been address and corrected by https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21346. |
Created attachment 10865 [details] Screenshot of double prompt - two options The following occurs after cancelling a hold on Holds Awaiting Pickup and being prompted that the item needs to be transferred to another library for the next person in the holds queue: First, the item status on the intranet detail screen says that the item is in transit, even though the request.pl/Holds screen does not register a tranfer! Second, when checking in a hold to be transferred (at least as a superlibrarian), the user is confronted with two prompts: 1) Please return <<item>> to <<transfer branch>>. Print slip or cancel transfer. Hold for <<patron>> Confirm. 2) Hold found <<item>>. Hold for <<patron>>. Confirm hold and transfer. If Option 1 is chosen, the <<transfer branch>> name is removed from the item status on the intranet detail screen. Other than that, nothing happens. If you try to check in again from the homebranch, you're prompted with the previous two options again. If you try to check in from the transfer branch, it requests that you transfer it to the transfer branch (which is quite bizarre). If Option 2 is chosen, the request.pl screen reflects the correct state of affairs. However, if you've chosen Option 1 first and then Option 2, when you change to the transfer branch, you're prompted with 2 similar options again! Option 1: Please return <<item>> to <<transfer branch>> (even though you're checking in to the transfer branch!!!) Option 2: Hold found. Confirm hold at <<transfer branch>> At this point, you're stuck in a loop. Regardless of the choice that you make, you CANNOT process the hold. You have to cancel the hold and start all over again.