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: | Circulation | Assignee: | 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: | ||
Circulation function: | |||
Bug Depends on: | |||
Bug Blocks: | 22160 |
Description
Victor Grousset/tuxayo
2018-03-06 15:58:34 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). == 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 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." |