Bug 20344 - Transferring an item while on hold results in a transfer where the destination is the same as the source
Summary: Transferring an item while on hold results in a transfer where the destinatio...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 22160
  Show dependency treegraph
 
Reported: 2018-03-06 15:58 UTC by Victor Grousset/tuxayo
Modified: 2021-06-02 11:08 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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?