http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8451 Christopher Brannon <cbrannon@cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon@cdalibrary.org --- Comment #2 from Christopher Brannon <cbrannon@cdalibrary.org> --- 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 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8451 --- Comment #4 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 13534 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=13534&action=edit 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8451 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |kyle@bywatersolutions.com |ity.org | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8451 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8451 Liz Rea (CatalystIT) <liz@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=9322 -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8451 Liz Rea (CatalystIT) <liz@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |liz@catalyst.net.nz --- Comment #8 from Liz Rea (CatalystIT) <liz@catalyst.net.nz> --- 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 -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8451 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #10 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- 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. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8451 Heather Braum <hbraum@nekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hbraum@nekls.org -- You are receiving this mail because: You are watching all bug changes.