Bug 20344

Summary: Transferring an item while on hold results in a transfer where the destination is the same as the source
Product: Koha Reporter: Victor Grousset/tuxayo <victor>
Component: CirculationAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: alexbuckley, gmcharlt, jonathan.druart, josef.moravec, kyle.m.hall, martin.renvoize, sophie.meynieux
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19530
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20885
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on:    
Bug Blocks: 22160    

Description Victor Grousset/tuxayo 2018-03-06 15:58:34 UTC
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
Comment 1 Victor Grousset/tuxayo 2018-03-06 17:31:01 UTC
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).
Comment 2 Victor Grousset/tuxayo 2018-03-06 18:31:02 UTC
== 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
Comment 3 Victor Grousset/tuxayo 2018-04-24 08:53:33 UTC Comment hidden (obsolete)
Comment 4 Victor Grousset/tuxayo 2018-04-24 08:54:31 UTC Comment hidden (obsolete)
Comment 5 Victor Grousset/tuxayo 2018-04-24 09:10:39 UTC Comment hidden (obsolete)
Comment 6 Martin Renvoize 2021-03-15 17:00:10 UTC
Quietly wondering if all the transfers refactoring has resolved this one now?
Comment 7 Victor Grousset/tuxayo 2021-06-02 11:08:58 UTC
> 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?
Comment 8 Owen Leonard 2024-04-24 14:48:20 UTC
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."