[Bug 33446] New: Revert transit status should have the option to cancel the item transfer as well
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Bug ID: 33446 Summary: Revert transit status should have the option to cancel the item transfer as well Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: emily.lamancusa@montgomerycountymd.gov QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com Currently, when a hold's transit status is reverted, the item remains in-transit until the transfer is completed by a check-in. This makes sense if the item actually is still in-transit, but there are other situations in which this transit status is incorrect and may not be easy to remove. For example, in our system, we have HoldsAutoFill enabled. Occasionally there are exceptions where we don't want a book to be put in transit for a hold, but instead to remain available at its home branch. If the staff member reverts the transit status on the hold, the item still shows as In Transit. But they can't check in the item to complete the transfer without causing the hold to trap again. In this situation, the book shouldn't be showing as In Transit, but there's no simple way to remove that status. It's several extra steps at best to manually cancel the transfer (and most of our staff don't know how to do this, as manual transfers are not a normal part of our workflow, so many items retain an incorrect "In transit" status indefinitely). When a hold's transit status is reverted by the sending librarian because they're not planning on sending the book for whatever reason, it would be great if they could revert the hold transit status and cancel the item transfer all in one step. This could be something as simple as a checkbox option or a drop-down, so that the user can choose between "Revert transit status" versus "Revert transit status and cancel item transfer". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Juliet Heltibridle <jheltibridle@rcplib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jheltibridle@rcplib.org --- Comment #1 from Juliet Heltibridle <jheltibridle@rcplib.org> --- Something like this would be very useful for our library as well. We use a SIP connection to check in our materials, and we have HoldsNeedProcessingSIP set to Fulfill so that items that are checked in by the Sort Assistant will automatically fill and print the slip. When we have problems with our courier system, sometimes we have to wait a few weeks to fill holds from other libraries. We can revert the status of the transfer on these holds, but instead of showing as available and on the shelf at our library, it displays the message that the transit is pending. We have to cancel the hold and place it again, or go through the steps of checking the item in at the other library, ignoring the hold, and then checking it in again at our library, ignoring the hold again. Ideally, when a transit is reverted, checking it in again at the owning library but ignoring the hold would update the status to available without the pending transfer. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 carthur@slolibrary.org <carthur@slolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carthur@slolibrary.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.delahunty@arts.ac.uk --- Comment #2 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- *** Bug 38991 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bdaeuber@cityoffargo.com --- Comment #3 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- *** Bug 38396 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=34756 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Kris <kbecker@jcls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kbecker@jcls.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Michelle Spinney <mspinney@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mspinney@clamsnet.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette@bywatersolutions.co | |m -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Kristi Krueger <kkrueger@cuyahogalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kkrueger@cuyahogalibrary.or | |g -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 mteal@greenvillelibrary.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mteal@greenvillelibrary.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 trevor.diamond@mainlib.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |trevor.diamond@mainlib.org --- Comment #4 from trevor.diamond@mainlib.org --- Going the "other direction" would be useful as well. If I check in a book and trap a hold (putting the item in transit), but then subsequently realize that the book is too damanged it's two parts to "fix" the hold. 1) Mark item as damaged 2) check in item : This comes up with the "item is in transit for a hold" modal. You have the option to cancel the transfer. 3) The hold has been changed to an item level hold and the hold status at this point is STILL "being transferred" to Sparta. Checking in the item and canceling the transfer should automatically update the related hold. The modal doesn't have any information about WHIcH hold the transfer is for, so the staff have no way to quickly go to the patron record and revert the hold. My test example was easy because there was only 1 hold on the biblio, but this would be a tedious task if you have lots of items and holds to wade though. In our organization, adding a second step from the patron (or biblio) revert hold screen is sub-optimal so I would want that to be optional, if offered. You have many reasons you might revert a hold which may or may not affect the item's transit status. However, taking an item OUT of transit will ALWAYS affect the related hold. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Rebecca Coert <rcoert@arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert@arlingtonva.us -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42583 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Melissa <mwalker@akronlibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mwalker@akronlibrary.org --- Comment #5 from Melissa <mwalker@akronlibrary.org> --- I agree with Trevor. We have a recent example of how not being able to clear the transit status is detrimental to workflows. We had a customer return a book damaged. For some reason, the staff person checking the material in didn't want to charge the customer, so moved to check the item in. The items could not float to the location they were working so Koha immediately put the item into transit to its owning location. The staff person then went to mark the item withdrawn, but couldn't. We have the system preference set to not allow staff to mark things withdrawn while they are in transit (for a few reason), but the main one being that we also don't allow items that are withdrawn to clear that status when they are checked in. They remain in withdrawn. Because of this, the item remains in transit for eternity. Staff must be able to easily reverse transit status that does not involve them changing their logged in library to the receiving end of the transit. I think that is unreasonable to ask staff to do that and can (and will) cause problems if they forget to change it back. I see no problem with the "cancel transit" button being available on the screen that asks to confirm transit when it is initially scanned in -- and any additional scans after that. There is no point in "confirming transit" if the only option is to confirm. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org