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
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).
== 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
Thanks to #19530, the first transfer should be cancelled, resolving half of the issue. See #19530#24
bug 19530#24
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)
Quietly wondering if all the transfers refactoring has resolved this one now?
> 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?
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."