[Bug 17338] New: waitingreserves.pl should keep you on the same tab when cancelling a hold
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 Bug ID: 17338 Summary: waitingreserves.pl should keep you on the same tab when cancelling a hold Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: cbrannon@cdalibrary.org QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com When you cancel a hold on the Hold(s) over tab, and the process is done, it puts you back on the Hold(s) waiting tab. It should keep you on the same tab. It would also be nice if the search box is used that it would keep the focus. We use the following jQuery to help streamline the cancelling process: //Default Holds awaiting pickup to Holds over tab $("#holdso form[action='waitingreserves.pl']").attr("action","waitingreserves.pl#holdsover"); if (window.location.href.indexOf("cgi-bin/koha/circ/waitingreserves.pl#holdsover")
-1) { $("form[action='waitingreserves.pl']").attr("action","waitingreserves.pl#holdsover"); } setTimeout(function() { $("#holdso_filter input").focus(); },10); //End default tab
-- 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=17338 Christopher Brannon <cbrannon@cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=17150 -- 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=17338 Lisette <lisetteslatah@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisetteslatah@gmail.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@bywatersolutions.com --- Comment #1 from Nick Clemens <nick@bywatersolutions.com> --- Hi Christopher, waitingreserves.pl should now keep you on the same tab once bug 23192 is addressed. Can you explain the focus? I am not sure what you mean. Should the page default to focus in the search/filter box for the table of reserves? -Nick -- 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=17338 --- Comment #2 from Christopher Brannon <cbrannon@cdalibrary.org> --- This is an old request. If there were an option to do that, it would be great. I don't think it should just focus on that search filter always, but if there were a check box to keep the focus, that would streamline the use of this page for those that are going through a pile of holds that need to be 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=17338 --- Comment #3 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to Christopher Brannon from comment #2)
This is an old request. If there were an option to do that, it would be great. I don't think it should just focus on that search filter always, but if there were a check box to keep the focus, that would streamline the use of this page for those that are going through a pile of holds that need to be cancelled.
I am afraid I don't understand - can you describe the workflow where focus is lost? Do you mean if you search, then click a cancel link, the focus should return to the search? i.e. if the search box is populated we should focus there on page load? -- 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=17338 Ray Delahunty <r.delahunty@arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.delahunty@arts.ac.uk --- Comment #4 from Ray Delahunty <r.delahunty@arts.ac.uk> --- When Christopher talks about the "loss of focus" does he mean that the loss of both the sort order and the limitation to a specific library? We have 6 libraries and the workflow staff are accustomed to was to limit to their branch, sort by user name order, and then go along the hold shelf removing the items and cancelling the hold and returning the item to the shelf (or setting the item aside for return to library it belongs to, or triggering the next hold). Now the loss of focus includes the need to move back to the RHS tab, limit to library again, and sort again. BTW the bug 23192 has already lead to data damage where staff have accidently cancelled an unfulfilled hold (one on the tab they were forced back to!). Our support company were unsuccessful in back porting the fix for 23192 into our 18.11 Koha version. -- 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=17338 --- Comment #5 from Christopher Brannon <cbrannon@cdalibrary.org> --- (In reply to Nick Clemens from comment #3)
(In reply to Christopher Brannon from comment #2)
This is an old request. If there were an option to do that, it would be great. I don't think it should just focus on that search filter always, but if there were a check box to keep the focus, that would streamline the use of this page for those that are going through a pile of holds that need to be cancelled.
I am afraid I don't understand - can you describe the workflow where focus is lost? Do you mean if you search, then click a cancel link, the focus should return to the search? i.e. if the search box is populated we should focus there on page load?
Yes. That is correct. If you look at the jquery, it does exactly what I am explaining. -- 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=17338 --- Comment #6 from Christopher Brannon <cbrannon@cdalibrary.org> --- (In reply to Christopher Brannon from comment #5)
(In reply to Nick Clemens from comment #3)
(In reply to Christopher Brannon from comment #2)
This is an old request. If there were an option to do that, it would be great. I don't think it should just focus on that search filter always, but if there were a check box to keep the focus, that would streamline the use of this page for those that are going through a pile of holds that need to be cancelled.
I am afraid I don't understand - can you describe the workflow where focus is lost? Do you mean if you search, then click a cancel link, the focus should return to the search? i.e. if the search box is populated we should focus there on page load?
Yes. That is correct. If you look at the jquery, it does exactly what I am explaining.
(In reply to Ray Delahunty from comment #4)
When Christopher talks about the "loss of focus" does he mean that the loss of both the sort order and the limitation to a specific library? We have 6 libraries and the workflow staff are accustomed to was to limit to their branch, sort by user name order, and then go along the hold shelf removing the items and cancelling the hold and returning the item to the shelf (or setting the item aside for return to library it belongs to, or triggering the next hold). Now the loss of focus includes the need to move back to the RHS tab, limit to library again, and sort again. BTW the bug 23192 has already lead to data damage where staff have accidently cancelled an unfulfilled hold (one on the tab they were forced back to!). Our support company were unsuccessful in back porting the fix for 23192 into our 18.11 Koha version.
Loss of focus means the cursor is not staying on the search box at the top of the list. Nothing to do with sort. I see how that it could be beneficial to keep the sort though. On any page for that matter. -- 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=17338 --- Comment #7 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Still valid or valid again. -- 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=17338 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |blawlor@clamsnet.org Status|NEW |CONFIRMED --- Comment #8 from Brendan Lawlor <blawlor@clamsnet.org> --- This is valid again since 24.11 It was reported to us after upgrading that cancelling a hold that is waiting past it's expiration date using the button in the actions column reloads the page on the first tab instead of keeping you on the expired tab. It seems related to the Bootstrap upgrade, possibly some code with the tab named like 'holdsover' needs to be updated to 'holdsover_panel' -- 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=17338 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com --- Comment #9 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- I have been unable to recreate this bug in current main. I have attempted to do so in both Firefox and Chrome. -- 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=17338 --- Comment #10 from Brendan Lawlor <blawlor@clamsnet.org> --- To recreate: 1. Place multiple holds, good to have at least 4, for pickup at a location, I used Nick's handy script 2. Perl misc/cronjobs/holds/build_holds_queue.pl 3. Check in at least 4 items for pickup at one location so they'll be wating 4. Update the expiration date on those holds using ktd --dbshell update reserves set expirationdate = DATE('2024-01-01') where branchcode='CPL'; 5. On Circulation > Holds waiting past their expiration date tab use the cancel button that is in the actions column to cancel a hold The page loads on the Holds waiting tab, although in the url you see /circ/waitingreserves.pl#holdsover It's only for the button in the actions column. If you select a row with the checkbox and use the cancel selected button it keeps you on the same tab -- 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=17338 --- Comment #11 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> ---
It's only for the button in the actions column. If you select a row with the checkbox and use the cancel selected button it keeps you on the same tab
Ah, thanks! That was my problem. :) -- 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=17338 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |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=17338 --- Comment #12 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- Created attachment 179670 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179670&action=edit Bug 17338: Fix anchor to redirect properly when canceling holds over X To test: 1. Place multiple holds, good to have at least 4, for pickup at a location, I used Nick's handy script 2. Perl misc/cronjobs/holds/build_holds_queue.pl 3. Check in at least 4 items for pickup at one location so they'll be wating 4. Update the expiration date on those holds using ktd --dbshell update reserves set expirationdate = DATE('2024-01-01') where branchcode='CPL'; 5. On Circulation > Holds waiting past their expiration date tab use the cancel button that is in the actions column to cancel a hold The page loads on the Holds waiting tab, although in the url you see /circ/waitingreserves.pl#holdsover 6. APPLY PATCH 7. Try 1 - 5 again, this time after step 5 you should be redirected. -- 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=17338 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Trivial patch Assignee|koha-bugs@lists.koha-commun |lucas@bywatersolutions.com |ity.org | -- 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=17338 Andrew Auld <andrew.auld@openfifth.co.uk> 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=17338 Andrew Auld <andrew.auld@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179670|0 |1 is obsolete| | --- Comment #13 from Andrew Auld <andrew.auld@openfifth.co.uk> --- Created attachment 180203 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180203&action=edit Bug 17338: Fix anchor to redirect properly when canceling holds over X To test: 1. Place multiple holds, good to have at least 4, for pickup at a location, I used Nick's handy script 2. Perl misc/cronjobs/holds/build_holds_queue.pl 3. Check in at least 4 items for pickup at one location so they'll be wating 4. Update the expiration date on those holds using ktd --dbshell update reserves set expirationdate = DATE('2024-01-01') where branchcode='CPL'; 5. On Circulation > Holds waiting past their expiration date tab use the cancel button that is in the actions column to cancel a hold The page loads on the Holds waiting tab, although in the url you see /circ/waitingreserves.pl#holdsover 6. APPLY PATCH 7. Try 1 - 5 again, this time after step 5 you should be redirected. Signed-off-by: Andrew Auld <andrew.auld@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=17338 Andrew Auld <andrew.auld@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew.auld@openfifth.co.uk --- Comment #14 from Andrew Auld <andrew.auld@openfifth.co.uk> --- Thanks for all the help getting to the sign off part in KTD! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |blawlor@clamsnet.org |y.org | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #15 from Brendan Lawlor <blawlor@clamsnet.org> --- Thanks for working on this Lucas. This works when the action button says 'Cancel hold', but if the button says 'Cancel and return to: [library]' then when you click the 'OK' button it returns you to the first tab 'Holds waiting' To recreate you need to have some more holds that can be fulfilled at your branch and other branches when you cancel a hold that's waiting past its expiration date. I think these other two forms cancelReservewithtransfert and cancelReservewithwaiting just need to pass the tab param and adjust their action attribute a bit. The anchor in the action url waitingreserves.pl#holdsover_panel does not load the tab, but as a parameter waitingreserves.pl?tab=holdsover_panel loads the correct tab. For example this works when a transfer is triggered: <form name="cancelReservewithtransfert" action="waitingreserves.pl" method="get"> <button type="submit" class="btn btn-default approve"><i class="fa fa-fw fa-check"></i> OK</button> <input type="hidden" name="tab" value="[% tab | html %]" /> </form> The other question I have is on waiting reserves.pl from line 47: if ( $item && $tab eq 'holdsover' && !@cancel_result ) { print $input->redirect("/cgi-bin/koha/circ/waitingreserves.pl#holdsover"); } elsif ( $op eq 'cud-cancelall' ) { print $input->redirect("/cgi-bin/koha/circ/waitingreserves.pl"); } I think this needs some work because now tab will be holdsover_panel, and also the redirect no longer seems to need the anchor in the url. Could this now be combined? While testing another bug I noticed is that when cancelling the hold triggers a transfer, the library's name does not render in the alert: line 57: <h2>This item is on hold for pick-up at [% Branches.GetName( branchname ) | html %]</h2> That should be written as [% Branches.GetName( branchcode ) | html %] I filed that bug 39569 and will post a patch soon. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 --- Comment #16 from Brendan Lawlor <blawlor@clamsnet.org> --- I found this comment and patch that is related to how these tabs work that should be helpful: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36064#c25 The url with an anchor to the holds waiting past their expiration tab that works is actually: http://localhost:8081/cgi-bin/koha/circ/waitingreserves.pl?#holdsover-tab With this revelation the info in my previous comment may not be 100% accurate :) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 Lucas Gass (lukeg) <lucas@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=17338 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #180203|0 |1 is obsolete| | --- Comment #17 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- Created attachment 181631 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=181631&action=edit Bug 17338: Fix redirection to correct tabs on waitingreserves.pl To test: 1. Place multiple holds, good to have at least 4, for pickup at a location, I used Nick's handy script 2. Perl misc/cronjobs/holds/build_holds_queue.pl 3. Check in at least 4 items for pickup at one location so they'll be wating 4. Update the expiration date on those holds using ktd --dbshell update reserves set expirationdate = DATE('2024-01-01') where branchcode='CPL'; 5. On Circulation > Holds waiting past their expiration date tab use the cancel button that is in the actions column to cancel a hold The page loads on the Holds waiting tab, although in the url you see /circ/waitingreserves.pl?tab=holdsover 6. APPLY PATCH 7. Try 1 - 5 again, this time after step 5 you should be redirected. 8. Try cancelling holds with a transfer, ensuring you get redirected correctly. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 Brendan Lawlor <blawlor@clamsnet.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=17338 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #181631|0 |1 is obsolete| | --- Comment #18 from Brendan Lawlor <blawlor@clamsnet.org> --- Created attachment 181830 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=181830&action=edit Bug 17338: Fix redirection to correct tabs on waitingreserves.pl To test: 1. Place multiple holds, good to have at least 4, for pickup at a location, I used Nick's handy script 2. Perl misc/cronjobs/holds/build_holds_queue.pl 3. Check in at least 4 items for pickup at one location so they'll be wating 4. Update the expiration date on those holds using ktd --dbshell update reserves set expirationdate = DATE('2024-01-01') where branchcode='CPL'; 5. On Circulation > Holds waiting past their expiration date tab use the cancel button that is in the actions column to cancel a hold The page loads on the Holds waiting tab, although in the url you see /circ/waitingreserves.pl?tab=holdsover 6. APPLY PATCH 7. Try 1 - 5 again, this time after step 5 you should be redirected. 8. Try cancelling holds with a transfer, ensuring you get redirected correctly. Signed-off-by: Andrew Auld <andrew.auld@openfifth.co.uk> Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA --- Comment #19 from Brendan Lawlor <blawlor@clamsnet.org> --- This patch works to keep the user on the same tab when cancelling holds using the button in the actions column on the holds awaiting pickup page, when there are transfers and when there are more holds for pickup at your library. The patch is trivial, so I hope it's ok that I added Andrew's sign off line back in when I signed off. Nice work. Passing QA. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|waitingreserves.pl should |'Holds awaiting pickup' |keep you on the same tab |should keep you on the same |when cancelling a hold |tab when cancelling a hold -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main Version(s)| |25.05.00 released in| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 --- Comment #20 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=17338 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- 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=17338 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |When cancelling hold release notes| |requests that haven't been | |picked up, it would jump | |back to the first tab after | |saving. Now Koha will | |display the correct tab | |after saving. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 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.05 released in| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 --- Comment #21 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Nice work everyone! Pushed to 24.11.x for 24.11.05 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 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=17338 Wainui Witika-Park <wainuiwitikapark@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |Needs documenting CC| |wainuiwitikapark@catalyst.n | |et.nz --- Comment #22 from Wainui Witika-Park <wainuiwitikapark@catalyst.net.nz> --- Not backporting to 22.11.x as it wasn't backported to 24.05.x -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org