[Bug 20344] New: Transferring an item while on hold results in a transfer were the destination is the same as the source
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20344 Bug ID: 20344 Summary: Transferring an item while on hold results in a transfer were the destination is the same as the source Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs@lists.koha-community.org Reporter: victor.grousset@biblibre.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle.m.hall@gmail.com 1. Check out an item 2. Place a hold on the specific item with a pickup at a different branch 3. Check in: Confirm hold and transfert 4. Check the branchtransfers table to ensure that the transfert is here SELECT * FROM branchtransfers order by datesent DESC LIMIT 10; 5. Home › Circulation › Transfers 6. Create a transfer identical as the existing one 7. You should see «Item is already at destination library.» 8. Check the branchtransfers table 1. First one should have been canceled «Canceled, new transfer from A to A created» 2. Another one should have been created from A to A 3. These 2 things are the issue. Because doing the same without a hold - doesn't create a new transfer - doesn't cancel the first one -- 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=20344 --- Comment #1 from Victor Grousset/tuxayo <victor.grousset@biblibre.com> --- Same behavior on 17.11.03 On 16.11.15, step 8: The first hold isn't cancelled, creating a duplicate transfert (without the same destinations). -- 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=20344 Victor Grousset/tuxayo <victor.grousset@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal -- 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=20344 --- Comment #2 from Victor Grousset/tuxayo <victor.grousset@biblibre.com> --- == Simpler test plan == On master. 1. Place a hold 2. Transfer the item twice (wherever, it can be the same transfer) 3. Check the branchtransfers table SELECT * FROM branchtransfers order by datesent DESC LIMIT 10; 4. First one should have been canceled «Canceled, new transfer from A to A created» 5. Another one should have been created from A to A 6. These 2 things are the issue. Because doing the same without a hold - doesn't create a new transfer - doesn't cancel the first one -- 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=20344 Sophie MEYNIEUX <sophie.meynieux@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Transferring an item while |Transferring an item while |on hold results in a |on hold results in a |transfer were the |transfer where the |destination is the same as |destination is the same as |the source |the source CC| |sophie.meynieux@biblibre.co | |m -- 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=20344 Victor Grousset/tuxayo <victor.grousset@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=19530 -- 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=20344 Josef Moravec <josef.moravec@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |josef.moravec@gmail.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20344 Alex Buckley <alexbuckley@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexbuckley@catalyst.net.nz Assignee|koha-bugs@lists.koha-commun |alexbuckley@catalyst.net.nz |ity.org | Status|NEW |ASSIGNED -- 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=20344 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@bugs.koha-c | |ommunity.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20344 --- Comment #3 from Victor Grousset/tuxayo <victor.grousset@biblibre.com> --- Thanks to #19530, the first transfer should be cancelled, resolving half of the issue. See #19530#24 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20344 --- Comment #4 from Victor Grousset/tuxayo <victor.grousset@biblibre.com> --- bug 19530#24 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20344 --- Comment #5 from Victor Grousset/tuxayo <victor.grousset@biblibre.com> --- Forget, the previous comments. I was confused when rereading the test plans and though bug 19530 wasn't in master at that time. (marking the comments as obsolete) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20344 Victor Grousset/tuxayo <victor.grousset@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=20885 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20344 Alex Buckley <alexbuckley@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW Assignee|alexbuckley@catalyst.net.nz |koha-bugs@lists.koha-commun | |ity.org -- 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=20344 Josef Moravec <josef.moravec@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |22160 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22160 [Bug 22160] OMNIBUS: Transfers enhancements -- 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=20344 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com --- Comment #6 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Quietly wondering if all the transfers refactoring has resolved this one now? -- 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=20344 --- Comment #7 from Victor Grousset/tuxayo <victor@tuxayo.net> ---
4. First one should have been canceled «Canceled, new transfer from A to A created»
Notes, it's about the comment column. In current master, this message isn't there anymore. It was there at least until 17.11 (https://pro-demo1711-koha.test.biblibre.eu)
6. These 2 things are the issue. Because doing the same without a hold - doesn't create a new transfer - doesn't cancel the first one
Without a hold. A new transfer is created and the old one is canceled. With a hold when doing "Ignore and return to transfers: " A new transfer is created and the old one is canceled. With a hold when doing "Waiting" A new transfer is created and the old one is canceled. An item hold doesn't change this. So, it happens regardless of the hold. 17.11: Without hold, just doing several transfers, none additional is created, the table is untouched (no timestamp change) So, is there something wrong? -- 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=20344 --- Comment #8 from Owen Leonard <oleonard@myacpl.org> --- What I'm seeing is that if I transfer a random item (no holds) multiple times I see multiple entries in the branchtransfers table. The same is not true of an item which is on hold and has already been transferred. However, if you transfer an on-hold item which is already in transit you get these choices: - Cancel hold and then attempt transfer - Ignore and return to transfers I think that makes it clear that the original transfer is going to stay in place if you choose to "Ignore." -- 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=20344 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |blawlor@clamsnet.org --- Comment #9 from Brendan Lawlor <blawlor@clamsnet.org> --- I think this is still valid, or maybe it's a slightly different bug. We've got reports of duplicate transfers currently happening in production and I was also able to reproduce in main. To replicate: 1. With no holds, at library A check in an item owned by Library B 2. A branch transfer for Return to Home is triggered (Check in message: Not checked out) 3. Now place a hold on the bib record for pickup at library C 4. Check the item in at library A again 5. A new branch transfer is created for reason Reserve 6. The original ReturnToHome transfer is not cancelled 7. select * from branchtransfers to confirm no cancellationdate in the first transfer Maybe this is partially by design because you can't actually tell if an item is really in transit to return home, or if it accidentally got put back on the shelf at library A instead of going in delivery. In returns.pl there are two lines with this comment that enqueues a transfer if one is already in the queue: # Add transfer, enqueue if one is already in the queue, and immediately set to in transit my $transfer = $item->request_transfer( { to => $tobranch, reason => 'Reserve', enqueue => 1 } ); I wonder if either of those situations should use replace => 'Reserve' instead of enqueue => 1 I tested and changing to use replace instead of enqueue adds a datecancelled and cancellation_reason to the existing transfer instead of leaving it as a pending transfer. -- 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