[Bug 9322] New: If multiple transfers exist (from circ/branchtransfers.pl), completing one completes them all
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9322 Bug ID: 9322 Summary: If multiple transfers exist (from circ/branchtransfers.pl), completing one completes them all Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: liz@catalyst.net.nz CC: gmcharlt@gmail.com To replicate: * get an item's barcode * go to circulation -> transfers * select a branch to transfer to * put in your barcode * submit the transfer * select a different branch to transfer to * (I don't know why you would do this, but) put your same barcode in again * submit the transfer * select a third branch to transfer to * (again, I don't know why you would do this, but) put your same barcode in again * submit the transfer A query against the database will show 3 transfers: select * from branchtransfers; +------------+---------------------+------------+---------------------+----------+---------------+ | itemnumber | datesent | frombranch | datearrived | tobranch | comments | +------------+---------------------+------------+---------------------+----------+---------------+ | 989 | 2012-12-27 14:31:14 | CPL | | FFL | NULL | | 989 | 2012-12-27 14:31:20 | FFL | | FRL | NULL | | 989 | 2012-12-27 14:34:22 | FRL | | CPL | NULL | You can see it's done something kind of smart, by putting the 2nd transfer to go from the destination of the first transfer. Makes good sense. What doesn't make such good sense is that when you complete the first transfer, the following happens: select * from branchtransfers; +------------+---------------------+------------+---------------------+----------+---------------+ | itemnumber | datesent | frombranch | datearrived | tobranch | comments | +------------+---------------------+------------+---------------------+----------+---------------+ | 989 | 2012-12-27 14:31:14 | CPL | 2012-12-27 14:34:36 | FFL | NULL | | 989 | 2012-12-27 14:31:20 | FFL | 2012-12-27 14:34:36 | FRL | NULL | | 989 | 2012-12-27 14:34:22 | FRL | 2012-12-27 14:34:36 | CPL | NULL | +------------+---------------------+------------+---------------------+----------+---------------+ All three transfers are received when the first one is. The other two don't trigger. It's like they never existed. I think this also happens when you have a reserve triggered transit in addition to a circ/branchtransfers.pl transit. This is the cause of the occasional "Item on hold for <patron>, item is already waiting" messages when you would normally be expecting a "Confirm hold for <patron>" message. -- 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=9322 --- Comment #1 from Liz Rea (CatalystIT) <liz@catalyst.net.nz> --- This will only happen if you return the item at the first one in the series - any other combination will trigger a "return this item to the branch that is expecting it" - for example item supposed to go cpl -> ffl, item returned at mpl Message: please return to FFL - this is fine and good. Do note, however, that no wrongtransfer is generated in this scenario. It probably should be, as we might want a record that it had gone to mpl instead of ffl. Currently there is none for branch transfers. (I think wrongtransfer only happens on transits initiated by reserves - but I could be wrong about that). -- 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=9322 --- Comment #2 from Liz Rea (CatalystIT) <liz@catalyst.net.nz> --- Another very bad no good scenario - say you have some transits placed independently of reserves: +------------+---------------------+------------+---------------------+----------+---------------+ | itemnumber | datesent | frombranch | datearrived | tobranch | comments | +------------+---------------------+------------+---------------------+----------+---------------+ | 989 | 2012-12-27 15:25:38 | CPL | NULL | RPL | NULL | | 989 | 2012-12-27 15:25:45 | RPL | NULL | SPL | NULL | | 989 | 2012-12-27 15:25:51 | SPL | NULL | UPL | NULL | Then you get one that goes with a reserve: +------------+---------------------+------------+---------------------+----------+---------------+ | itemnumber | datesent | frombranch | datearrived | tobranch | comments | +------------+---------------------+------------+---------------------+----------+---------------+ | 989 | 2012-12-27 15:25:38 | CPL | NULL | RPL | NULL | | 989 | 2012-12-27 15:25:45 | RPL | NULL | SPL | NULL | | 989 | 2012-12-27 15:25:51 | SPL | NULL | UPL | NULL | | 989 | 2012-12-27 15:32:32 | SPL | NULL | CPL | NULL | +------------+---------------------+------------+---------------------+----------+---------------+ Your staff member, seeing dual prompts (because you will see dual prompts here), receives the item - all of the transits are marked arrived (and thus lost), and no matter how many times you check this item in, nothing will happen - the reserve is hung up, the transits are gone, it's in a properly bad way. This will require human intervention and detective work to get out of: +------------+---------------------+------------+---------------------+----------+---------------+ | itemnumber | datesent | frombranch | datearrived | tobranch | comments | +------------+---------------------+------------+---------------------+----------+---------------+ | 989 | 2012-12-27 15:25:38 | CPL | 2012-12-27 15:33:00 | RPL | NULL | | 989 | 2012-12-27 15:25:45 | RPL | 2012-12-27 15:33:00 | SPL | NULL | | 989 | 2012-12-27 15:25:51 | SPL | 2012-12-27 15:33:00 | UPL | NULL | | 989 | 2012-12-27 15:32:32 | SPL | 2012-12-27 15:33:00 | CPL | NULL | +------------+---------------------+------------+---------------------+----------+---------------+ -- 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=9322 Liz Rea (CatalystIT) <liz@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=8451 -- 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=9322 --- Comment #3 from Liz Rea (CatalystIT) <liz@catalyst.net.nz> --- bug 8292 introduces an automaticitemreturn transfer that will trigger this as well. -- 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=9322 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com --- Comment #4 from Kyle M Hall <kyle@bywatersolutions.com> --- Would it not make sense for any given item to only ever have a single row in the branch transfers table at any given time? I.e. initiating a transfer from LibraryA to LibraryB, and then a transfer from LibraryA to LibraryC will cause the system to delete the A to B, and replace it with A to C. I cannot think of a scenario where multiple open branch transfers for a single item are useful. -- 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=9322 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major -- 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=9322 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |8292 -- 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=9322 --- Comment #5 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 15059 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15059&action=edit Bug 9322 - If multiple transfers exist (from circ/branchtransfers.pl), completing one completes them all This patch prevents multiple unresolved item transfers for a given item to exist at the same time. Test Plan: 1) Get an item's barcode 2) Go to circulation -> transfers 3) Select a branch to transfer to 4) Put in your barcode 5) Submit the transfer 6) Examine the branchtransfers table, note that there is now one open transfer for the item 7) Select a different branch to transfer to 8) Put your same barcode in again 9) Submit the transfer 10) Reexamine the branchtransfers table, note that the previous open transfer has been removed and the new open transfer has replaced it. -- 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=9322 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff Patch complexity|--- |Trivial patch -- 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=9322 --- Comment #6 from Kyle M Hall <kyle@bywatersolutions.com> --- This patch deletes the unresolved but 'overwritten' transfers. It may be a good idea to keep them around for historical data purposes, and set the date to '0000-00-00 00:00:00' to mark them as resolved but never completed. -- 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=9322 --- Comment #7 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 15060 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15060&action=edit Bug 9322 - 'Resolve' previous open transfer when adding a new transfer for a given item This patch prevents multiple unresolved item transfers for a given item to exist at the same time. If an item has an open transfer and is subject to a second open transfer, the previous open transfer will be given a datearrived time of '0000-00-00 00:00:00' to indicate the transfer was resolved but never completed. Test Plan: 1) Get an item's barcode 2) Go to circulation -> transfers 3) Select a branch to transfer to 4) Put in your barcode 5) Submit the transfer 6) Examine the branchtransfers table, note that there is now one open transfer for the item 7) Select a different branch to transfer to 8) Put your same barcode in again 9) Submit the transfer 10) Reexamine the branchtransfers table, note that the previous open transfer has been removed and the new open transfer has replaced it. -- 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=9322 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #15060|0 |1 is obsolete| | --- Comment #8 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 15061 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15061&action=edit Bug 9322 - 'Resolve' previous open transfer when adding a new transfer for a given item This patch prevents multiple unresolved item transfers for a given item to exist at the same time. If an item has an open transfer and is subject to a second open transfer, the previous open transfer will be given a datearrived time of '0000-00-00 00:00:00' to indicate the transfer was resolved but never completed. Test Plan: 1) Get an item's barcode 2) Go to circulation -> transfers 3) Select a branch to transfer to 4) Put in your barcode 5) Submit the transfer 6) Examine the branchtransfers table, note that there is now one open transfer for the item 7) Select a different branch to transfer to 8) Put your same barcode in again 9) Submit the transfer 10) Reexamine the branchtransfers table, note that the previous open transfer now has a datearrived value of '0000-00-00 00:00:00' and the new transfer is the only transfer for this item with a datearrived value of NULL -- 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=9322 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #15059|0 |1 is obsolete| | --- Comment #9 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 15062 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15062&action=edit Bug 9322 - Delete previous open transfer when adding a new transfer for a given item This patch prevents multiple unresolved item transfers for a given item to exist at the same time. Test Plan: 1) Get an item's barcode 2) Go to circulation -> transfers 3) Select a branch to transfer to 4) Put in your barcode 5) Submit the transfer 6) Examine the branchtransfers table, note that there is now one open transfer for the item 7) Select a different branch to transfer to 8) Put your same barcode in again 9) Submit the transfer 10) Reexamine the branchtransfers table, note that the previous open transfer has been deleted and the new open transfer has replaced it. -- 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=9322 --- Comment #10 from Kyle M Hall <kyle@bywatersolutions.com> --- There are now two mutually exclusive patches to resolve this issue. One deletes previous open transfers from the database, the other marks them as arrived with an arrival date of '0000-00-00 00:00:00'. Please pick the one you feel is the better implementation and deprecate the alternative when you sign off on the patch. -- 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=9322 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=9322 MJ Ray (software.coop) <mjr@software.coop> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mjr@software.coop --- Comment #11 from MJ Ray (software.coop) <mjr@software.coop> --- Could you ask on koha mailing list/forums which approach librarians would prefer? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9322 --- Comment #12 from Liz Rea <liz@catalyst.net.nz> --- I don't personally like either of these approaches - I think only the transfer being completed should be completed - if it's for a reserve, it should only cancel the reserve transfer. I was thinking maybe stash the reserve number in the comment or create a new field for "what kind of transfer it is (reserve, with a number, or branchtransfer, with branchtransfer.)" -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9322 --- Comment #13 from Galen Charlton <gmcharlt@gmail.com> --- (In reply to comment #12)
I don't personally like either of these approaches - I think only the transfer being completed should be completed - if it's for a reserve, it should only cancel the reserve transfer.
I was thinking maybe stash the reserve number in the comment or create a new field for "what kind of transfer it is (reserve, with a number, or branchtransfer, with branchtransfer.)"
I think adding the reserve number to the transfer record would be useful, although I prefer doing it as a real, nullable foreign key rather than sticking it in the comments. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9322 --- Comment #14 from Galen Charlton <gmcharlt@gmail.com> --- And while we're in the area ... this would be a good time to assign a numeric PK to branchtransfers. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9322 MJ Ray (software.coop) <mjr@software.coop> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion --- Comment #15 from MJ Ray (software.coop) <mjr@software.coop> --- This is being discussed on koha-devel in Feb/March. One summary was http://koha.1045719.n5.nabble.com/Opinions-needed-on-bug-9322-td5744019.html but I'm not sure whether that means either of these patches could be used - I think "a librarian might legitimately want to do chained transfers" means something else needs to be done. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9322 Nick Clemens <nick@quecheelibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@quecheelibrary.org -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9322 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.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org