[Bug 29792] New: Transfers created from Wrong Transfer checkin are not sent if modal is dismissed
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 Bug ID: 29792 Summary: Transfers created from Wrong Transfer checkin are not sent if modal is dismissed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs@lists.koha-community.org Reporter: andrew@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle.m.hall@gmail.com Depends on: 23092 To recreate: 1 - have an item in transit from Branch A to Branch B 2 - check the item in at Branch A 3 - get a Wrong Transfer message, click Print Slip or OK 4 - query the branchtransfers table, see that your original transfer was cancelled and a new one was made, confirm that new transfer has a datesent value 5 - repeat steps 1-3, but instead of clicking one of the buttons click outside of the modal to make it go away 6 - query the branchtransfers table, see that your original transfer was cancelled and a new one was made, confirm that new transfer DOES NOT HAVE a datesent value So that transfer is just hanging out as requested and the item needs to get checked in again to get it sent. This is a change in behavior, as before bug 23092 the second transfer would be sent immediately even if one clicked away from the modal without selecting anything. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23092 [Bug 23092] Add 'daterequested' to the transfers table -- 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=29792 --- Comment #1 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- I should have included that one must have TransfersBlockCirc turned off in order to click away from the modal without selecting something. Also, scanning in another barcode without addressing the modal has the same effect as clicking away from it. -- 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=29792 Jason Robb <jrobb@sekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jrobb@sekls.org --- Comment #2 from Jason Robb <jrobb@sekls.org> --- This is causing disruption in our consortial setting. It is not uncommon to check an item in multiple times. It is also not uncommon for a library to overlook prompts without clicking the buttons on those prompts. Before, if a library checked in an item returning home twice consecutively, it remained in transit. Now, if a library checks in an item returning home twice consecutively, it gets taken out of transit and the item appears Available at the wrong library. As the behavior has changed, this has led to a non-trivial amount of items in our catalog showing Available when they were thought to be in transit. It would be great if the previous behavior were restored, where any number of check-ins on a returning item kept it in transit to its home library (unless something else derails it like a newly placed hold). Otherwise, this creates a large amount of previously unnecessary work to track and retrigger transfers that were mistakenly canceled due to multiple check-ins. -- 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=29792 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@bywatersolutions.com Assignee|koha-bugs@lists.koha-commun |nick@bywatersolutions.com |ity.org | See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=25755 Depends on| |24434 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24434 [Bug 24434] C4::Circulation::updateWrongTransfer is never called but should be -- 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=29792 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 --- Comment #3 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 129008 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=129008&action=edit Bug 29792: Automatically send wrong transfers Bug 24434 reinstated the 'updateWrongTransfer' call here, but made the assertion that the transfer should not be sent until 'Ok' was clicked. I see how unsent transfers are useful for rotation, but I believe for wrong trasnfer we shouldn't require a confirm or print. If a library does want to, the 'transfersblockcirc' system preference will enforce clicking the button to continue To test: 1 - have an item in transit from Branch A to Branch B 2 - check the item in at Branch A 3 - get a Wrong Transfer message, click Print Slip or OK 4 - query the branchtransfers table, see that your original transfer was cancelled and a new one was made, confirm that new transfer has a datesent value 5 - repeat steps 1-3, but instead of clicking one of the buttons click outside of the modal to make it go away 6 - query the branchtransfers table, see that your original transfer was cancelled and a new one was made, confirm that new transfer DOES NOT HAVE a datesent value 7 - Apply patch 8 - Repeat the check in 9 - New transfer is generated and has 'datesent' set -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 --- Comment #4 from AspenCat Team <aspencatteam@clicweb.org> --- We have not seen reports of this yet, but I can definitely see this being an issue for our consortium. There will be times that items do get checked in multiple times, and that would create some of the same havoc that Jason is talking about - Bob Bennhoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 Andrew Fuerste-Henry <andrew@bywatersolutions.com> 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=29792 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #129008|0 |1 is obsolete| | --- Comment #5 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 129009 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=129009&action=edit Bug 29792: Automatically send wrong transfers Bug 24434 reinstated the 'updateWrongTransfer' call here, but made the assertion that the transfer should not be sent until 'Ok' was clicked. I see how unsent transfers are useful for rotation, but I believe for wrong trasnfer we shouldn't require a confirm or print. If a library does want to, the 'transfersblockcirc' system preference will enforce clicking the button to continue To test: 1 - have an item in transit from Branch A to Branch B 2 - check the item in at Branch A 3 - get a Wrong Transfer message, click Print Slip or OK 4 - query the branchtransfers table, see that your original transfer was cancelled and a new one was made, confirm that new transfer has a datesent value 5 - repeat steps 1-3, but instead of clicking one of the buttons click outside of the modal to make it go away 6 - query the branchtransfers table, see that your original transfer was cancelled and a new one was made, confirm that new transfer DOES NOT HAVE a datesent value 7 - Apply patch 8 - Repeat the check in 9 - New transfer is generated and has 'datesent' set Signed-off-by: Andrew Fuerste-Henry <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=29792 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@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=29792 --- Comment #6 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Leaving a note to self for when I QA properly next week. Why are we changing the signature for request_transfer here? The idea was to keep the methods singularly focused with defined exceptions. In short, shouldn't we be chaining the returned trans ft er request with a call to transit... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 --- Comment #7 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Right.. so the idea of the transfers work was to try and remove the quasi-state of not knowing if an item is actually in transit or not... thus we have 'requested' and 'sent' dates to distinguish. If we go back to defaulting to 'sent' in this case, we're going back to not actually knowing if the item has actually been sent or not. Also, from an end-user perspective, the general rule for a modal is to 'fail-safe'. i.e if you ignore a modal then the 'close' action is used by default.. in this case, that is 'do nothing' i.e. don't trigger a cancellation, but also don't trigger to say we've actually loaded the item into the van. We could change the default action to for WrongTransfer to immediately call 'transit' to put the item into transit (set the sent date), we could do the same in circ/returns.pl or we could do it in the template with javascript to automatically trigger the 'ok' action of the modal if one clicks away. But, in all those cases we're ended up with an unknown that some libraries would prefer to avoid. Perhaps we could tie it to another system preference, 'AutomaticWrongTransfer' such that the default of the modal is 'OK' if closed without clicking a button? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 --- Comment #8 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> ---
But, in all those cases we're ended up with an unknown that some libraries would prefer to avoid. Perhaps we could tie it to another system preference, 'AutomaticWrongTransfer' such that the default of the modal is 'OK' if closed without clicking a button?
A syspref seems like a good answer. We clearly have two strong preferences among users about what assumption Koha should make when this modal dismissed. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 --- Comment #9 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- OK, I'll try to add that alternative patch later today.. got a couple of meetings first so bear with ;) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=28294 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #10 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Martin Renvoize from comment #9)
OK, I'll try to add that alternative patch later today.. got a couple of meetings first so bear with ;)
Martin, do you still plan to provide an alternative patch or should we move on with what we have here? As there seems to be a need for a pref, I'll set to failed QA for now. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 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=29792 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |31663 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31663 [Bug 31663] Item not showing transit status on catalogue/detail.pl -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 Nick Clemens <nick@bywatersolutions.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=29792 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #129009|0 |1 is obsolete| | --- Comment #11 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 141124 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=141124&action=edit Bug 29792: Automatically send wrong transfers Bug 24434 reinstated the 'updateWrongTransfer' call here, but made the assertion that the transfer should not be sent until 'Ok' was clicked. I see how unsent transfers are useful for rotation, but I believe for wrong transfer we shouldn't require a confirm or print. If a library does want to, the 'transfersblockcirc' system preference will enforce clicking the button to continue This patch also confirms a transfer when item already has a transfer and only options are Confirm/Print because the transfer already exists To test: 1 - Disable TransfersBlockCirc system preference 2 - Manually transfer an item from branch A to branch B 3 - Check in the item at branch A 4 - Dismiss modal without confirming 5 - View item on biblio details page, item not in transit 6 - Check in item, confirm transfer 7 - Note item in transit on details page 8 - Check in the item at branch C 9 - Dismiss modal without confirm 10 - View item on biblio detail, not in transit 11 - Checkin at A, cancel transfer 12 - Apply patch 13 - repeat 1 - 4 14 - Confirm item appears in transit 15 - Check in at branch C, dismiss modal 16 - Confirm item in transit -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 --- Comment #12 from Nick Clemens <nick@bywatersolutions.com> --- Amended test plan - after manually transferring, check-in and ignore wrong transfer modal - next check-in generates the 'item-transfer-modal' -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #141124|0 |1 is obsolete| | --- Comment #13 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 141576 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=141576&action=edit Bug 29792: Automatically send wrong transfers Bug 24434 reinstated the 'updateWrongTransfer' call here, but made the assertion that the transfer should not be sent until 'Ok' was clicked. I see how unsent transfers are useful for rotation, but I believe for wrong transfer we shouldn't require a confirm or print. If a library does want to, the 'transfersblockcirc' system preference will enforce clicking the button to continue This patch also confirms a transfer when item already has a transfer and only options are Confirm/Print because the transfer already exists To test: 1 - Disable TransfersBlockCirc system preference 2 - Manually transfer an item from branch A to branch B 3 - Check in the item at branch A 4 - Dismiss modal without confirming 5 - View item on biblio details page, item not in transit 6 - Check in item, confirm transfer 7 - Note item in transit on details page 8 - Check in the item at branch C 9 - Dismiss modal without confirm 10 - View item on biblio detail, not in transit 11 - Checkin at A, cancel transfer 12 - Apply patch 13 - repeat 1 - 4 14 - Confirm item appears in transit 15 - Check in at branch C, dismiss modal 16 - Confirm item in transit Signed-off-by: Martin Renvoize <martin.renvoize@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=29792 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #14 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Thanks for taking this over Nick.. looks great and works as described.. Signing off. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |katrin.fischer@bsz-bw.de |y.org | Summary|Transfers created from |Transfers created from |Wrong Transfer checkin are |'wrong transfer' checkin |not sent if modal is |are not sent if modal is |dismissed |dismissed -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Medium patch 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=29792 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #141576|0 |1 is obsolete| | --- Comment #15 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 143049 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=143049&action=edit Bug 29792: Automatically send wrong transfers Bug 24434 reinstated the 'updateWrongTransfer' call here, but made the assertion that the transfer should not be sent until 'Ok' was clicked. I see how unsent transfers are useful for rotation, but I believe for wrong transfer we shouldn't require a confirm or print. If a library does want to, the 'transfersblockcirc' system preference will enforce clicking the button to continue This patch also confirms a transfer when item already has a transfer and only options are Confirm/Print because the transfer already exists To test: 1 - Disable TransfersBlockCirc system preference 2 - Manually transfer an item from branch A to branch B 3 - Check in the item at branch A 4 - Dismiss modal without confirming 5 - View item on biblio details page, item not in transit 6 - Check in item, confirm transfer 7 - Note item in transit on details page 8 - Check in the item at branch C 9 - Dismiss modal without confirm 10 - View item on biblio detail, not in transit 11 - Checkin at A, cancel transfer 12 - Apply patch 13 - repeat 1 - 4 14 - Confirm item appears in transit 15 - Check in at branch C, dismiss modal 16 - Confirm item in transit Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |22.11.00 released in| | Status|Passed QA |Pushed to master -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 --- Comment #16 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Pushed to master for 22.11. Nice work everyone, thanks! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|Pushed to master |RESOLVED 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=29792 --- Comment #17 from Lucas Gass <lucas@bywatersolutions.com> --- I would be happy to backport this but it does not apply cleanly to 22.05.x. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 --- Comment #18 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 146726 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=146726&action=edit Bug 29792: [22.05.x] Automatically send wrong transfers Bug 24434 reinstated the 'updateWrongTransfer' call here, but made the assertion that the transfer should not be sent until 'Ok' was clicked. I see how unsent transfers are useful for rotation, but I believe for wrong transfer we shouldn't require a confirm or print. If a library does want to, the 'transfersblockcirc' system preference will enforce clicking the button to continue This patch also confirms a transfer when item already has a transfer and only options are Confirm/Print because the transfer already exists To test: 1 - Disable TransfersBlockCirc system preference 2 - Manually transfer an item from branch A to branch B 3 - Check in the item at branch A 4 - Dismiss modal without confirming 5 - View item on biblio details page, item not in transit 6 - Check in item, confirm transfer 7 - Note item in transit on details page 8 - Check in the item at branch C 9 - Dismiss modal without confirm 10 - View item on biblio detail, not in transit 11 - Checkin at A, cancel transfer 12 - Apply patch 13 - repeat 1 - 4 14 - Confirm item appears in transit 15 - Check in at branch C, dismiss modal 16 - Confirm item in transit Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|22.11.00 |22.11.00,22.05.10 released in| | --- Comment #19 from Lucas Gass <lucas@bywatersolutions.com> --- Backported to 22.05.x for upcoming 22.05.10 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arthur.suzuki@biblibre.com Version(s)|22.11.00,22.05.10 |22.11.00,22.05.10, 21.11.18 released in| | --- Comment #20 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- The patch for 22.05.x also applies clean on 21.11.x. Applied for 21.11.18! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 wainuiwitikapark@catalyst.net.nz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wainuiwitikapark@catalyst.n | |et.nz --- Comment #21 from wainuiwitikapark@catalyst.net.nz --- Not backported to 21.05.x -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |33300 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33300 [Bug 33300] Wrong system preference name AutomaticWrongTransfer -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29792 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Documentation| |Caroline Cyr La Rose contact| | Documentation| |https://gitlab.com/koha-com submission| |munity/koha-manual/-/merge_ | |requests/669 CC| |caroline.cyr-la-rose@inlibr | |o.com -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org