[Bug 38793] New: Transfer silently not canceled when TransfersBlockCirc = "don't block" and AutomaticConfirmTransfer = "do automatically confirm"
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Bug ID: 38793 Summary: Transfer silently not canceled when TransfersBlockCirc = "don't block" and AutomaticConfirmTransfer = "do automatically confirm" Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs@lists.koha-community.org Reporter: victor@tuxayo.net QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle.m.hall@gmail.com To reproduce: 0. Set TransfersBlockCirc = "don't block" AutomaticConfirmTransfer = "do automatically confirm" 1. Find or create an item that belongs to a branch other than the logged-in branch Like 39999000012118 in test data 2. Check in the item - this should trigger a Return to Home transfer 3. Click OK on the modal to confirm the transfer 4. Check in that item again 5. Cancel the transfer 6. Open the bib record for that item in a new tab 7. It's still in transit (that's wrong!) 8. Check in that item again 9. It still offers to cancel. (confirming the previous cancel attempt didn't work) Logs don't show any error. -- 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=38793 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=38789, | |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=38588 -- 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=38793 --- Comment #1 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 176189 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=176189&action=edit Bug 38793: Don't dismiss modal before submitting form Remove the bs-data-dismiss attribute from the "cancel transfer" button on the Wrong Transfer modal. The "cancel transfer" button's JS works by adding a hidden input and then submitting the form - we don't want Bootstrap to dismiss the modal before the embedded form has been submitted. To test: 0. Set up system preferences: TransfersBlockCirc - Don't block AutomaticConfirmTransfer - Do 1. Find or create an item that belongs to a branch other than the logged-in branch 2. Check in the item to trigger a Return to Home transfer 3. Click OK on the modal to confirm the transfer 4. Check in the item again to trigger a Wrong Transfer modal 5. Click the "Cancel transfer" button on the modal 6. Navigate to the bib for that item and check the item status --> The transfer wasn't cancelled - the item is still in transit 7. Apply patch and refresh the page 8. Repeat steps 4-6 --> Item shows as available - the transfer was cancelled successfully -- 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=38793 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emily.lamancusa@montgomeryc | |ountymd.gov Patch complexity|--- |Trivial patch Status|NEW |Needs Signoff Depends on| |38588 --- Comment #2 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Turns out Bootstrap was dismissing the modal before the form submitted the request to cancel the transfer...which caused AutomaticConfirmTransfer to confirm it in the absence of other input. The test plan produces internal server errors without the patches from 38588, so I'm adding that as a dependency. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38588 [Bug 38588] Checkin that triggers a transfer => print slip => Internal server error -- 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=38793 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |38842 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 [Bug 38842] Refactor modal logic in returns.tt / returns.pl -- 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=38793 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com Assignee|koha-bugs@lists.koha-commun |emily.lamancusa@montgomeryc |ity.org |ountymd.gov --- Comment #3 from David Nind <david@davidnind.com> --- I had a go at testing. However, I'm not noticing any difference in behavour before and after the patch. Testing notes - both before and after the patch:[1] - before step 6 the item is showing as in transit (as expected after the first check in) - after the second check in and selecting "Cancel transfer (X)": . the current library is showing as Centerville (as expected) . the home library is showing as Midway (as expected) . not shown as in transit I had to apply bug 38588 before starting the test plan, to get rid of the error trace. [1] Used record 165 - Higher-order Perl : transforming programs with programs, item barcode 39999000007077 (before check ins, current and home library shown as Midway) -- 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=38793 --- Comment #4 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- (In reply to David Nind from comment #3)
I had a go at testing.
However, I'm not noticing any difference in behavour before and after the patch.
Testing notes - both before and after the patch:[1] - before step 6 the item is showing as in transit (as expected after the first check in) - after the second check in and selecting "Cancel transfer (X)": . the current library is showing as Centerville (as expected) . the home library is showing as Midway (as expected) . not shown as in transit
I had to apply bug 38588 before starting the test plan, to get rid of the error trace.
[1] Used record 165 - Higher-order Perl : transforming programs with programs, item barcode 39999000007077 (before check ins, current and home library shown as Midway)
Thanks for testing! Hmmmm...that's what Victor said too, but I still reproduce it with bug 38588 applied and this bug not applied. I only reproduce it with the system preference settings from step 0, though, not with default settings. You're still seeing the above after changing the sysprefs? If so, maybe it's browser-based? I'm using Firefox. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 --- Comment #5 from David Nind <david@davidnind.com> --- (In reply to Emily Lamancusa (emlam) from comment #4)
Thanks for testing! Hmmmm...that's what Victor said too, but I still reproduce it with bug 38588 applied and this bug not applied. I only reproduce it with the system preference settings from step 0, though, not with default settings. You're still seeing the above after changing the sysprefs? If so, maybe it's browser-based? I'm using Firefox.
I was testing using Chromium. I just tested with Firefox, and I got the behavour as described in the test plan. It seems of that it works differently in different browsers - I tried to see if there were any console errors, but couldn't see any. Can confirm that system preferences as per step 0 of the test plan were set. I don't know enough to identify what might be causing this - maybe Owen might have an idea. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 --- Comment #6 from Victor Grousset/tuxayo <victor@tuxayo.net> --- (In reply to Emily Lamancusa (emlam) from comment #4)
Thanks for testing! Hmmmm...that's what Victor said too
It was for another ticket. Or maybe it's applicable here? Because here I get everything as expected with Firefox. But yes with Chromium I can't reproduce the issue, there is indeed a difference in behavior! 😱 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oleonard@myacpl.org --- Comment #7 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- (In reply to Victor Grousset/tuxayo from comment #6)
(In reply to Emily Lamancusa (emlam) from comment #4)
Thanks for testing! Hmmmm...that's what Victor said too
It was for another ticket. Or maybe it's applicable here? Because here I get everything as expected with Firefox.
But yes with Chromium I can't reproduce the issue, there is indeed a difference in behavior! 😱
It was something you mentioned on bug 38806, yeah... Though now that I go back and reread, I'm not sure if we were talking about the same thing ^^" I'll update the test plan in the patch to note that it seems to be specific to Firefox (I couldn't replicate it in Chrome or Edge either). Owen, would you mind taking a look? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #176189|0 |1 is obsolete| | --- Comment #8 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 176368 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=176368&action=edit Bug 38793: Don't dismiss modal before submitting form Remove the bs-data-dismiss attribute from the "cancel transfer" button on the Wrong Transfer modal. The "cancel transfer" button's JS works by adding a hidden input and then submitting the form - we don't want Bootstrap to dismiss the modal before the embedded form has been submitted. Note: This bug seems to be browser-dependent. So far it has been reproduced with Firefox, but not Chrome/Chromium or Microsoft Edge To test: 1. Log into the staff client using Firefox 2. Set up system preferences: TransfersBlockCirc - Don't block AutomaticConfirmTransfer - Do 3. Find or create an item that belongs to a branch other than the logged-in branch 4. Check in the item to trigger a Return to Home transfer 5. Click OK on the modal to confirm the transfer 6. Check in the item again to trigger a Wrong Transfer modal 7. Click the "Cancel transfer" button on the modal 8. Navigate to the bib for that item and check the item status --> The transfer wasn't cancelled - the item is still in transit 9. Apply patch and refresh the page 10. Repeat steps 6-8 --> Item shows as available - the transfer was cancelled successfully -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #176368|0 |1 is obsolete| | --- Comment #9 from Owen Leonard <oleonard@myacpl.org> --- Created attachment 176387 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=176387&action=edit Bug 38793: Don't dismiss modal before submitting form Remove the bs-data-dismiss attribute from the "cancel transfer" button on the Wrong Transfer modal. The "cancel transfer" button's JS works by adding a hidden input and then submitting the form - we don't want Bootstrap to dismiss the modal before the embedded form has been submitted. Note: This bug seems to be browser-dependent. So far it has been reproduced with Firefox, but not Chrome/Chromium or Microsoft Edge To test: 1. Log into the staff client using Firefox 2. Set up system preferences: TransfersBlockCirc - Don't block AutomaticConfirmTransfer - Do 3. Find or create an item that belongs to a branch other than the logged-in branch 4. Check in the item to trigger a Return to Home transfer 5. Click OK on the modal to confirm the transfer 6. Check in the item again to trigger a Wrong Transfer modal 7. Click the "Cancel transfer" button on the modal 8. Navigate to the bib for that item and check the item status --> The transfer wasn't cancelled - the item is still in transit 9. Apply patch and refresh the page 10. Repeat steps 6-8 --> Item shows as available - the transfer was cancelled successfully Signed-off-by: Owen Leonard <oleonard@myacpl.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #176387|0 |1 is obsolete| | --- Comment #10 from Victor Grousset/tuxayo <victor@tuxayo.net> --- Created attachment 176404 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=176404&action=edit Bug 38793: Don't dismiss modal before submitting form Remove the bs-data-dismiss attribute from the "cancel transfer" button on the Wrong Transfer modal. The "cancel transfer" button's JS works by adding a hidden input and then submitting the form - we don't want Bootstrap to dismiss the modal before the embedded form has been submitted. Note: This bug seems to be browser-dependent. So far it has been reproduced with Firefox, but not Chrome/Chromium or Microsoft Edge To test: 1. Log into the staff client using Firefox 2. Set up system preferences: TransfersBlockCirc - Don't block AutomaticConfirmTransfer - Do 3. Find or create an item that belongs to a branch other than the logged-in branch 4. Check in the item to trigger a Return to Home transfer 5. Click OK on the modal to confirm the transfer 6. Check in the item again to trigger a Wrong Transfer modal 7. Click the "Cancel transfer" button on the modal 8. Navigate to the bib for that item and check the item status --> The transfer wasn't cancelled - the item is still in transit 9. Apply patch and refresh the page 10. Repeat steps 6-8 --> Item shows as available - the transfer was cancelled successfully Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net> Signed-off-by: Owen Leonard <oleonard@myacpl.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #176404|0 |1 is obsolete| | --- Comment #11 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 176849 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=176849&action=edit Bug 38793: Don't dismiss modal before submitting form Remove the bs-data-dismiss attribute from the "cancel transfer" button on the Wrong Transfer modal. The "cancel transfer" button's JS works by adding a hidden input and then submitting the form - we don't want Bootstrap to dismiss the modal before the embedded form has been submitted. Note: This bug seems to be browser-dependent. So far it has been reproduced with Firefox, but not Chrome/Chromium or Microsoft Edge To test: 1. Log into the staff client using Firefox 2. Set up system preferences: TransfersBlockCirc - Don't block AutomaticConfirmTransfer - Do 3. Find or create an item that belongs to a branch other than the logged-in branch 4. Check in the item to trigger a Return to Home transfer 5. Click OK on the modal to confirm the transfer 6. Check in the item again to trigger a Wrong Transfer modal 7. Click the "Cancel transfer" button on the modal 8. Navigate to the bib for that item and check the item status --> The transfer wasn't cancelled - the item is still in transit 9. Apply patch and refresh the page 10. Repeat steps 6-8 --> Item shows as available - the transfer was cancelled successfully Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net> Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@gmail.com --- Comment #12 from Jonathan Druart <jonathan.druart@gmail.com> --- Didn't test, but it has been tested 3x already. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |release-notes-needed --- Comment #13 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I wonder if we could make the bug description a bit more general an dmove some of the info into the release notes? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |25.05.00 released in| | Status|Passed QA |Pushed to main -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 --- Comment #14 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Pushed for 25.05! Well done everyone, thank you! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |38954 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38954 [Bug 38954] checkout type column should be hidden by colvis -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|38954 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38954 [Bug 38954] checkout type column should be hidden by colvis -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |Fixes a transfer being release notes| |silently not canceled | |(despite clicking the | |button) when system | |preferences | |TransfersBlockCirc = "don't | |block" and | |AutomaticConfirmTransfer = | |"do automatically confirm". | |Which should only be about | |confirming when dismissing | |the transfer modal. Summary|Transfer silently not |When setting up automatic |canceled when |confirmation of transfers |TransfersBlockCirc = "don't |when dismissing the modal. |block" and |It prevents manual |AutomaticConfirmTransfer = |cancellation |"do automatically confirm" | --- Comment #15 from Victor Grousset/tuxayo <victor@tuxayo.net> --- (In reply to Katrin Fischer from comment #13)
I wonder if we could make the bug description a bit more general an dmove some of the info into the release notes?
Here is a go at it. Anyone is free to change stuff again. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|release-notes-needed | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |rel_24_11_candidate CC| |lucas@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Pushed to stable Version(s)|25.05.00 |25.05.00,24.11.03 released in| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 --- Comment #16 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Nice work everyone! Pushed to 24.11.x for 24.11.03 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul.derscheid@lmscloud.de Keywords|rel_24_11_candidate | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Bug 38793 depends on bug 38588, which changed state. Bug 38588 Summary: Checkin that triggers a transfer => print slip => Internal server error https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38588 What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |Needs documenting CC| |fridolin.somers@biblibre.co | |m -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED CC| |caroline.cyr-la-rose@inlibr | |o.com Status|Needs documenting |RESOLVED --- Comment #17 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- This looks like a bug fix. Nothing to change in the manual. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org