Summary: | 'Holds awaiting pickup' should keep you on the same tab when cancelling a hold | ||
---|---|---|---|
Product: | Koha | Reporter: | Christopher Brannon <cbrannon> |
Component: | Hold requests | Assignee: | Lucas Gass (lukeg) <lucas> |
Status: | Pushed to stable --- | QA Contact: | Brendan Lawlor <blawlor> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | andrew.auld, blawlor, gmcharlt, lisette, lucas, nick, paul.derscheid, r.delahunty |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17150 | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | Trivial patch | Documentation contact: | |
Documentation submission: | Text to go in the release notes: |
When cancelling hold 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.
|
|
Version(s) released in: |
25.05.00,24.11.05
|
Circulation function: | |
Attachments: |
Bug 17338: Fix anchor to redirect properly when canceling holds over X
Bug 17338: Fix anchor to redirect properly when canceling holds over X Bug 17338: Fix redirection to correct tabs on waitingreserves.pl Bug 17338: Fix redirection to correct tabs on waitingreserves.pl |
Description
Christopher Brannon
2016-09-23 15:01:50 UTC
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 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. (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? 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. (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 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. Still valid or valid again. 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' I have been unable to recreate this bug in current main. I have attempted to do so in both Firefox and Chrome. 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
> 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. :)
Created attachment 179670 [details] [review] 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. Created attachment 180203 [details] [review] 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> Thanks for all the help getting to the sign off part in KTD! 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. 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 :) Created attachment 181631 [details] [review] 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. Created attachment 181830 [details] [review] 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> 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. Pushed for 25.05! Well done everyone, thank you! Nice work everyone! Pushed to 24.11.x for 24.11.05 |