Bug 41416 - Poor performance when clicking 'Update hold(s)' on request.pl for records with many holds
Summary: Poor performance when clicking 'Update hold(s)' on request.pl for records wit...
Status: Needs Signoff
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-12-09 18:58 UTC by Nick Clemens (kidclamp)
Modified: 2025-12-10 20:55 UTC (History)
4 users (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: ---
Comma delimited list of Sponsors:
Crowdfunding goal: 0
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 41416: Add skip_fix_priority option to ModReserve (9.75 KB, patch)
2025-12-09 19:07 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens (kidclamp) 2025-12-09 18:58:50 UTC
When updating holds priority or other fields on a record with many holds it can take a long time for the server to return.

Looking at the code we call ModReserve for each hold on the page - ModReserve call _FixPriority for each hold - _FixPriority loops through every hold on the record an updates the priority to ensure correct ordering.

The same outcome can be achieved in less time by calling _FixPriority a single time (per bib) after the loop
Comment 1 Nick Clemens (kidclamp) 2025-12-09 19:07:36 UTC
Created attachment 190383 [details] [review]
Bug 41416: Add skip_fix_priority option to ModReserve

This patch adds a new parameter to ModReserve: skip_fix_priority

The page for altering priority ensures each hold has a unique rank, so doesn't allow for setting two
holds to the same rank, so we don't need to reorder everything until the end (in case of some cancellations etc)

This patch also makes FixPriority exported and updates the name as it is already called in a few places outside of
C4:Reserve

To test:
 1 - Place many holds on a record, 50 - 150
     https://github.com/kidclamp/handy-koha-script/blob/main/randhold.pl
 2 - View the record in the staff interface:
     http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=312
 3 - Click on the 'Holds' tab
 4 - Adjust the priority of several holds using the dropdowns
 5 - Open the network tab in the browser console (F12) to view the timing
 6 - Click 'Update hold(s)' and note the time
 7 - Apply patch, restart all
 8 - Repeat
 9 - Confirm timing is better and numbering updates correctly
10 - Sign off!

Note: The script adds holds that may be marked as 'lowestPriority' these will always all group at the bottom of the record