Bug 34756 - Cancelling a hold does not cancel the related transfer
Summary: Cancelling a hold does not cancel the related transfer
Status: Needs Signoff
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Baptiste Wojtkowski (bwoj)
QA Contact: Emily Lamancusa (emlam)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-09-11 14:11 UTC by Julian Maurice
Modified: 2025-03-18 10:17 UTC (History)
10 users (show)

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


Attachments
Bug 34756: Cancelling a hold does not cancel the related transfer (6.02 KB, patch)
2024-06-27 14:27 UTC, Baptiste Wojtkowski (bwoj)
Details | Diff | Splinter Review
Bug 34756: Cancelling a hold does not cancel the related transfer (6.11 KB, patch)
2024-07-01 11:21 UTC, Jake Deery
Details | Diff | Splinter Review
Bug 34756: Cancelling a hold does not cancel the related transfer (6.10 KB, patch)
2024-10-22 13:02 UTC, Baptiste Wojtkowski (bwoj)
Details | Diff | Splinter Review
Bug 34756: Cancelling a hold does not cancel the related transfer (5.83 KB, patch)
2025-03-18 09:56 UTC, Baptiste Wojtkowski (bwoj)
Details | Diff | Splinter Review
Bug 34756: (follow-up) Rework the transfer cancellation modal (6.33 KB, patch)
2025-03-18 09:56 UTC, Baptiste Wojtkowski (bwoj)
Details | Diff | Splinter Review
Bug 34756: (follow-up) Rework the transfer cancellation modal (7.08 KB, patch)
2025-03-18 10:12 UTC, Baptiste Wojtkowski (bwoj)
Details | Diff | Splinter Review
Bug 34756: (follow-up) Rework the transfer cancellation modal (7.08 KB, patch)
2025-03-18 10:15 UTC, Baptiste Wojtkowski (bwoj)
Details | Diff | Splinter Review
Bug 34756: (follow-up) Rework the transfer cancellation modal (7.08 KB, patch)
2025-03-18 10:17 UTC, Baptiste Wojtkowski (bwoj)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Maurice 2023-09-11 14:11:42 UTC
When a hold is confirmed and its pickup location is different from the item's location, a transfer is initiated.
If the hold is cancelled, the item remains in transfer whereas it is no longer needed at the transfer destination.

Is this normal behaviour ? It seems that staff users should at least see a message about the transfer and maybe have the ability to cancel it.

Steps to reproduce:
1. Create an item at library A
2. Place a hold on this item with a pickup location at library B
3. Check in the item at library A
4. Confirm the hold. The item should now be in transit to library B
5. Cancel the hold. There is no message about the probably useless transfer.
Comment 1 Baptiste Wojtkowski (bwoj) 2024-06-27 14:27:19 UTC
Created attachment 168198 [details] [review]
Bug 34756: Cancelling a hold does not cancel the related transfer

When a hold is confirmed and its pickup location is different from the item's location, a transfer is initiated.
If the hold is cancelled, the item remains in transfer whereas it is no longer needed at the transfer destination.

Is this normal behaviour ? It seems that staff users should at least see a message about the transfer and maybe have the ability to cancel it.

Steps to reproduce:
1. Create an item at library A
2. Place a hold on this item with a pickup location at library B
3. Check in the item at library A
4. Confirm the hold. The item should now be in transit to library B
5. Cancel the hold. There is no message about the probably useless transfer.

NEW TEST PLAN
1. Create an item at library A
2. Place a hold on this item with a pickup location at library B
3. Check in the item at library A
3-bis. Try to cancel the hold: notice there is no message
4. Confirm the hold. The item should now be in transit to library B
5. Cancel the hold. There is now a message to propose you to cancel the
   related transfer
6. Do not check the checkbox. There is no hold but still a transfer
7. Repeat the whole process checking the checkbox. Thers is no hold and
   the transfer has been cancelled.
Comment 2 Jake Deery 2024-07-01 11:21:00 UTC
Created attachment 168313 [details] [review]
Bug 34756: Cancelling a hold does not cancel the related transfer

When a hold is confirmed and its pickup location is different from the item's location, a transfer is initiated.
If the hold is cancelled, the item remains in transfer whereas it is no longer needed at the transfer destination.

Is this normal behaviour ? It seems that staff users should at least see a message about the transfer and maybe have the ability to cancel it.

Steps to reproduce:
1. Create an item at library A
2. Place a hold on this item with a pickup location at library B
3. Check in the item at library A
4. Confirm the hold. The item should now be in transit to library B
5. Cancel the hold. There is no message about the probably useless transfer.

NEW TEST PLAN
1. Create an item at library A
2. Place a hold on this item with a pickup location at library B
3. Check in the item at library A
3-bis. Try to cancel the hold: notice there is no message
4. Confirm the hold. The item should now be in transit to library B
5. Cancel the hold. There is now a message to propose you to cancel the
   related transfer
6. Do not check the checkbox. There is no hold but still a transfer
7. Repeat the whole process checking the checkbox. Thers is no hold and
   the transfer has been cancelled.

Signed-off-by: Jake Deery <jake.deery@ptfs-europe.com>
Comment 3 Jake Deery 2024-07-01 11:27:06 UTC
Ran through the test plan and looks all good to me. It would be nice if, when checking in at Library B, the message said something like "return cancelled hold" instead of "return this item to library a"

I'm nitpicking, though, and this is probably not within the scope of this bug.

Signed off with thanks
Comment 4 Baptiste Wojtkowski (bwoj) 2024-07-10 07:43:05 UTC
Hi ! Thank you so much for signing off and commenting :)

I created a bug for your proposal, https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37299
I'll work on it once the QA validates the approach chosen in this one.
Comment 5 Baptiste Wojtkowski (bwoj) 2024-10-22 13:02:30 UTC
Created attachment 173138 [details] [review]
Bug 34756: Cancelling a hold does not cancel the related transfer

When a hold is confirmed and its pickup location is different from the item's location, a transfer is initiated.
If the hold is cancelled, the item remains in transfer whereas it is no longer needed at the transfer destination.

Is this normal behaviour ? It seems that staff users should at least see a message about the transfer and maybe have the ability to cancel it.

Steps to reproduce:
1. Create an item at library A
2. Place a hold on this item with a pickup location at library B
3. Check in the item at library A
4. Confirm the hold. The item should now be in transit to library B
5. Cancel the hold. There is no message about the probably useless transfer.

NEW TEST PLAN
1. Create an item at library A
2. Place a hold on this item with a pickup location at library B
3. Check in the item at library A
3-bis. Try to cancel the hold: notice there is no message
4. Confirm the hold. The item should now be in transit to library B
5. Cancel the hold. There is now a message to propose you to cancel the
   related transfer
6. Do not check the checkbox. There is no hold but still a transfer
7. Repeat the whole process checking the checkbox. Thers is no hold and
   the transfer has been cancelled.

Signed-off-by: Jake Deery <jake.deery@ptfs-europe.com>
Comment 6 Victor Grousset/tuxayo 2025-01-13 13:52:10 UTC
There is no change in the diff after the conflict resolution. So it looks very safe to still have the previous signoff valid. (even if the diff would have changed, it depend on if you feel that the changes would need resting)

Feel free to get back to need signoff if there is actually something that would warrant retesting.
Comment 7 Emily Lamancusa (emlam) 2025-01-24 16:06:12 UTC
I really like this idea! On a first review the code generally looks good. There are just a few things I think need to be clarified/adjusted:

First, I think the wording on the checkbox could be adjusted to make it a little clearer to library staff what will happen, though. Could it be a drop-down instead of a checkbox? Something like:
"Yes - Cancel transfer and keep the item here"
"No - Leave the item in transit"


Second, from request.pl:
+    my $transfer = $input->param("transfer-cancel") ? "1" : "0";
     my $hold                = Koha::Holds->find($reserve_id);
+
+    if( $transfer ) {
+        warn($hold->item()->get_transfer);
+        $hold->item()->get_transfer->cancel( { reason => 'Manual', 'force' => '1' } );
+    }

Why the warn? Also, I think it would be clearer to call the variable $transfer_cancel instead of $transfer, since that's really what it's about at this point in the code.
Comment 8 Emily Lamancusa (emlam) 2025-01-24 16:08:35 UTC
I'd love to see this behavior in a couple of other places too:
- When cancelling a hold from the patron account page
- When clicking the "Revert Transit Status" button

Not a blocker, just making a note of it for future reference :)
Comment 9 Ray Delahunty 2025-01-28 13:55:28 UTC
Bugzilla etiquette question. I have just set up a report that looks for items on hold / reserved that haven’t reached the pickup library within a few days so staff can quickly revert the transit status (in the reservation) to make the reservation go live again. But as Emily points out… it doesn’t go live. The In transit status (on the item) stays. While I have managed to get the ‘In transit pending’ status applied that’s not enough to restart the reservation. Should I raise a new bug here- possibly entitled Reverting a hold does not cancel the related transfer?
Comment 10 Emily Lamancusa (emlam) 2025-01-28 14:21:00 UTC
Hi Ray, yes, filing a new bug is the way to go for that. Thank you for saying something! (Really, I should have filed one when I said something earlier - that was an oversight on my part.) It's also a good idea to put this bug number in the "see also" field when you file the new one, to keep them together since they are related.
Comment 11 Baptiste Wojtkowski (bwoj) 2025-03-17 16:16:06 UTC
> Why the warn? Also, I think it would be clearer to call the variable
> $transfer_cancel instead of $transfer, since that's really what it's about at this > point in the code.

I ask the mercy of the QA team, this was my first patch on Koha /o/
I totally agree with both points. Concerning the checkbox, I'll think about a better solution: I don't like using dropdown menus when there are two options.
Comment 12 Baptiste Wojtkowski (bwoj) 2025-03-18 09:56:31 UTC
Created attachment 179425 [details] [review]
Bug 34756: Cancelling a hold does not cancel the related transfer

When a hold is confirmed and its pickup location is different from the item's location, a transfer is initiated.
If the hold is cancelled, the item remains in transfer whereas it is no longer needed at the transfer destination.

Is this normal behaviour ? It seems that staff users should at least see a message about the transfer and maybe have the ability to cancel it.

Steps to reproduce:
1. Create an item at library A
2. Place a hold on this item with a pickup location at library B
3. Check in the item at library A
4. Confirm the hold. The item should now be in transit to library B
5. Cancel the hold. There is no message about the probably useless transfer.

NEW TEST PLAN
1. Create an item at library A
2. Place a hold on this item with a pickup location at library B
3. Check in the item at library A
3-bis. Try to cancel the hold: notice there is no message
4. Confirm the hold. The item should now be in transit to library B
5. Cancel the hold. There is now a message to propose you to cancel the
   related transfer, check the information are correct.
6. Do not check the checkbox. There is no hold but still a transfer
7. Repeat the whole process checking the checkbox. Thers is no hold and
   the transfer has been cancelled.

Signed-off-by: Jake Deery <jake.deery@ptfs-europe.com>
Comment 13 Baptiste Wojtkowski (bwoj) 2025-03-18 09:56:35 UTC Comment hidden (obsolete)
Comment 14 Baptiste Wojtkowski (bwoj) 2025-03-18 10:12:07 UTC Comment hidden (obsolete)
Comment 15 Baptiste Wojtkowski (bwoj) 2025-03-18 10:15:56 UTC Comment hidden (obsolete)
Comment 16 Baptiste Wojtkowski (bwoj) 2025-03-18 10:17:49 UTC
Created attachment 179430 [details] [review]
Bug 34756: (follow-up) Rework the transfer cancellation modal