Bug 17338 - 'Holds awaiting pickup' should keep you on the same tab when cancelling a hold
Summary: 'Holds awaiting pickup' should keep you on the same tab when cancelling a hold
Status: Pushed to stable
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Lucas Gass (lukeg)
QA Contact: Brendan Lawlor
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-23 15:01 UTC by Christopher Brannon
Modified: 2025-05-26 18:18 UTC (History)
8 users (show)

See Also:
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 (2.20 KB, patch)
2025-03-24 18:27 UTC, Lucas Gass (lukeg)
Details | Diff | Splinter Review
Bug 17338: Fix anchor to redirect properly when canceling holds over X (2.25 KB, patch)
2025-04-01 14:27 UTC, Andrew Auld
Details | Diff | Splinter Review
Bug 17338: Fix redirection to correct tabs on waitingreserves.pl (3.85 KB, patch)
2025-04-28 16:53 UTC, Lucas Gass (lukeg)
Details | Diff | Splinter Review
Bug 17338: Fix redirection to correct tabs on waitingreserves.pl (3.95 KB, patch)
2025-05-01 14:41 UTC, Brendan Lawlor
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Brannon 2016-09-23 15:01:50 UTC
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
Comment 1 Nick Clemens (kidclamp) 2019-06-24 12:03:48 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
Comment 2 Christopher Brannon 2019-06-24 14:41:23 UTC
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.
Comment 3 Nick Clemens (kidclamp) 2019-06-25 12:03:37 UTC
(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?
Comment 4 Ray Delahunty 2019-08-08 07:25:25 UTC
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.
Comment 5 Christopher Brannon 2019-08-08 14:19:37 UTC
(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.
Comment 6 Christopher Brannon 2019-08-08 14:23:45 UTC
(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.
Comment 7 Katrin Fischer 2023-06-25 12:20:17 UTC
Still valid or valid again.
Comment 8 Brendan Lawlor 2025-03-05 18:39:17 UTC
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'
Comment 9 Lucas Gass (lukeg) 2025-03-24 15:36:56 UTC
I have been unable to recreate this bug in current main. I have attempted to do so in both Firefox and Chrome.
Comment 10 Brendan Lawlor 2025-03-24 18:02:51 UTC
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
Comment 11 Lucas Gass (lukeg) 2025-03-24 18:17:03 UTC
> 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. :)
Comment 12 Lucas Gass (lukeg) 2025-03-24 18:27:33 UTC
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.
Comment 13 Andrew Auld 2025-04-01 14:27:14 UTC
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>
Comment 14 Andrew Auld 2025-04-01 14:27:55 UTC
Thanks for all the help getting to the sign off part in KTD!
Comment 15 Brendan Lawlor 2025-04-04 18:34:13 UTC
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.
Comment 16 Brendan Lawlor 2025-04-09 21:07:14 UTC
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 :)
Comment 17 Lucas Gass (lukeg) 2025-04-28 16:53:58 UTC
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.
Comment 18 Brendan Lawlor 2025-05-01 14:41:57 UTC
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>
Comment 19 Brendan Lawlor 2025-05-01 14:48:54 UTC
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.
Comment 20 Katrin Fischer 2025-05-02 06:54:59 UTC
Pushed for 25.05!

Well done everyone, thank you!
Comment 21 Paul Derscheid 2025-05-26 18:17:43 UTC
Nice work everyone!

Pushed to 24.11.x for 24.11.05