[Bug 34756] New: Cancelling a hold does not cancel the related transfer
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Bug ID: 34756 Summary: Cancelling a hold does not cancel the related transfer Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs@lists.koha-community.org Reporter: julian.maurice@biblibre.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle.m.hall@gmail.com 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 --- Comment #1 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- Created attachment 168198 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=168198&action=edit 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |baptiste.wojtkowski@biblibr | |e.com Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com Assignee|koha-bugs@lists.koha-commun |baptiste.wojtkowski@biblibr |ity.org |e.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Jake Deery <jake.deery@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #168198|0 |1 is obsolete| | --- Comment #2 from Jake Deery <jake.deery@ptfs-europe.com> --- Created attachment 168313 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=168313&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Jake Deery <jake.deery@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jake.deery@ptfs-europe.com Status|Needs Signoff |Signed Off --- Comment #3 from Jake Deery <jake.deery@ptfs-europe.com> --- 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 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emily.lamancusa@montgomeryc | |ountymd.gov QA Contact|testopia@bugs.koha-communit |emily.lamancusa@montgomeryc |y.org |ountymd.gov -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 --- Comment #4 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|emily.lamancusa@montgomeryc |testopia@bugs.koha-communit |ountymd.gov |y.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Patch doesn't apply CC| |kyle@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #168313|0 |1 is obsolete| | --- Comment #5 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- Created attachment 173138 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=173138&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Emmanuel Bétemps <e.betemps@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |e.betemps@gmail.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off CC| |victor@tuxayo.net --- Comment #6 from Victor Grousset/tuxayo <victor@tuxayo.net> --- 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |emily.lamancusa@montgomeryc |y.org |ountymd.gov Status|Signed Off |Failed QA --- Comment #7 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 --- Comment #8 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- 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 :) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Ray Delahunty <r.delahunty@arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.delahunty@arts.ac.uk --- Comment #9 from Ray Delahunty <r.delahunty@arts.ac.uk> --- 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? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 --- Comment #10 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Ray Delahunty <r.delahunty@arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=38991 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 --- Comment #11 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> ---
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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #173138|0 |1 is obsolete| | --- Comment #12 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- Created attachment 179425 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179425&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 --- Comment #13 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- Created attachment 179426 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179426&action=edit Bug 34756: (follow-up) Rework the transfer cancellation modal -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179426|0 |1 is obsolete| | --- Comment #14 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- Created attachment 179428 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179428&action=edit Bug 34756: (follow-up) Rework the transfer cancellation modal -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179428|0 |1 is obsolete| | --- Comment #15 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- Created attachment 179429 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179429&action=edit Bug 34756: (follow-up) Rework the transfer cancellation modal -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179429|0 |1 is obsolete| | --- Comment #16 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- Created attachment 179430 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179430&action=edit Bug 34756: (follow-up) Rework the transfer cancellation modal -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 PTFS Europe Sandboxes <sandboxes@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179430|0 |1 is obsolete| | --- Comment #17 from PTFS Europe Sandboxes <sandboxes@ptfs-europe.com> --- Created attachment 180625 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180625&action=edit Bug 34756: (follow-up) Rework the transfer cancellation modal Signed-off-by: Mikko Liimatainen <mikko.liimatainen@turku.fi> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Mikko Liimatainen <mikko.liimatainen@turku.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off CC| |mikko.liimatainen@turku.fi --- Comment #18 from Mikko Liimatainen <mikko.liimatainen@turku.fi> --- This seems to work as intended. However there was an issue when I checked-in an item and confirmed hold transfer, then checked-in the same item again and ignored the transfer and then checked-in the item for a third time and confirmed the transfer. This causes a situation where there are two active transfer and this patch only cancels one. This causes there to be a transfer that should not be there. As far as I can tell this issue is caused independent of this patch so I signed-off on this. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Michelle Spinney <mspinney@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mspinney@clamsnet.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen@gmail.com Status|Signed Off |Failed QA --- Comment #19 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- I think this behavior should be baked into Koha::Hold->cancel. And tested. It seems that otherwise we will have to implement the same logic everywhere a hold cancellation happens (there are already comments about other places needing this treatment). As this is a behavior change, we will probably need to add a syspref or circ rule to control this, disabled by default. This could evolve -in separate report- into a more fine grained config. Do we have a way to know a transfer process has been initiated already? I imagine this can become problematic if the item is in a delivery truck already. not a blocker per se, just thinking out loud. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 --- Comment #20 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- I don't think I agree with putting this in delete : cancelling a hold must not delete the related transfer, for example removing from the OPAC, the user should not even be warned. As a developper, if I delete a hold, I don't want it to delete the associated transfer ; I need to have control over it. Moreover the interaction with the user should not be part of the ORM. Maybe I can move this to another include to make it easier to reuse ? I can add a Syspref but since it only adds a checkbox, which is unchecked by default, I'm not sure it would be a useful one. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 --- Comment #21 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Maybe I didn’t explain the whole idea well enough. I think the cancel() method needs to be added a parameter controlling the behavior. And the controller would pass it if conditions are met. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 --- Comment #22 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- (In reply to Tomás Cohen Arazi (tcohen) from comment #21)
Maybe I didn’t explain the whole idea well enough.
I think the cancel() method needs to be added a parameter controlling the behavior. And the controller would pass it if conditions are met.
Oh.. I missread, very sorry. I still don't get your point, I'm using transfer->cancel but I have no clue on how I would change it... Do you mean hold->cancel(), that would refuse cancelling if there is no explicit reference to the existing transfer ? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 --- Comment #23 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- (In reply to Baptiste Wojtkowski (bwoj) from comment #22)
(In reply to Tomás Cohen Arazi (tcohen) from comment #21)
Maybe I didn’t explain the whole idea well enough.
I think the cancel() method needs to be added a parameter controlling the behavior. And the controller would pass it if conditions are met.
Oh.. I missread, very sorry.
I still don't get your point, I'm using transfer->cancel but I have no clue on how I would change it... Do you mean hold->cancel(), that would refuse cancelling if there is no explicit reference to the existing transfer ?
I mean something like ``` diff --git a/Koha/Hold.pm b/Koha/Hold.pm index b3bf4a02b76..b4d185901e1 100644 --- a/Koha/Hold.pm +++ b/Koha/Hold.pm @@ -675,6 +675,8 @@ my $cancel_hold = $hold->cancel( [ charge_cancel_fee => 1||0, ] [ cancellation_reason => $cancellation_reason, ] [ skip_holds_queue => 1||0 ] + [ cancel_transfer => 1||0 ] + [ cancel_transfer_reason => 'some valid transfer' ] } ); @@ -703,6 +705,14 @@ sub cancel { $self->cancellation_reason( $params->{cancellation_reason} ); $self->store(); + my $item = $self->item; + + if ( $params->{cancel_transfer} ) { + my $transfer = $item->get_transfer(); + $transfer->cancel( $params->{cancel_transfer_reason} // 'Manual' ) + if $transfer; + } + my $dbh = $self->_result->result_source->schema->storage->dbh; $dbh->do( q{ @@ -766,7 +776,6 @@ sub cancel { # and, if desired, charge a cancel fee if ( $params->{'charge_cancel_fee'} ) { - my $item = $self->item; my $charge = Koha::CirculationRules->get_effective_expire_reserves_charge( { itemtype => $item->effective_itemtype, ``` -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=33446 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Rebecca Coert <rcoert@arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert@arlingtonva.us -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com Status|Signed Off |Patch doesn't apply -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 --- Comment #24 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Hi, I understand my comments might have put this user-facing development in a bad position. I will file a separate bug for what I'm proposing so the conversation moves forward without blocking this report, which is very useful for users. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Janne Seppänen <janne.seppanen@lahti.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |janne.seppanen@lahti.fi --- Comment #25 from Janne Seppänen <janne.seppanen@lahti.fi> --- We'd love to see a solution to this - we get a steady influx of questions from our staff wondering why the item from the hold they had to cancel is still in transit. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=43840 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 --- Comment #26 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- The code I proposed is totally obsolete AFAIK, I need to restart from zero -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org