Bug 40815 - Item Search -- Allow 1000 visible rows.
Summary: Item Search -- Allow 1000 visible rows.
Status: REOPENED
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: 24.11
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-09-15 23:17 UTC by Lillian
Modified: 2025-09-22 04:57 UTC (History)
2 users (show)

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


Attachments
Image of dropdown menu that ends at 100. (14.90 KB, image/jpeg)
2025-09-15 23:17 UTC, Lillian
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lillian 2025-09-15 23:17:55 UTC
Created attachment 186446 [details]
Image of dropdown menu that ends at 100.

Right now, 100 is the max number of visible rows we can select from Item Search results in order to export to Item Batch Modification. This means, for 1,600 results, I need to export the results 16 times. 

1000 is the max number of results that can be exported to Batch Modification at one time. Why not make this an option? 

If 1000 rows were an option in the dropdown menu (image attached). I would only have to export the Batch Modification 2 times. That's many fewer!

Thanks for your consideration!
Comment 1 Anneli Österman 2025-09-19 09:39:09 UTC
Where does the information that 1000 is the max number of results to be exported come from? 

You can change the maximum with MaxItemsToProcessForBatchMod system preference. I think we have batch modified up to 15 000 items at once in our libraries. We have set limit of 1000 to MaxItemsToDisplayForBatchMod because displaying 15 000 items in batch modification is too slow and ends up in proxy error / timeout. But you can still modify more than 1000 successfully even if they are not shown. Modifications go to the background jobs which allows you to modify larger batches than before the background jobs were added.

But yes, otherwise I also think that 100 is a bit small number when doing batch modifications and 1000 rows is a more useful option. :)
Comment 2 Lillian 2025-09-19 15:08:24 UTC
Thanks Anneli! I think changing that system preference will make things easier for our purposes! Our setting is at 1000. I will increase this and be happy!
Comment 3 Lillian 2025-09-19 15:22:26 UTC
Would increasing this number cause server strain? It might be better to add only 1000 records to batch mod at once. Unless there is a good max number that someone can recommend. I know it probably depends on how many changes we are making to the records at once.

Ultimately, I would still like 1000 to be an option on the display records, since it's the default Koha setting for MaxItemsToProcessForBatchMod preference.

Thanks again Anneli!
Comment 4 Anneli Österman 2025-09-22 04:57:14 UTC
I do not know the technical explanation but this is how they are described in the manual:

"Jobs are tasks that are queued in the system to be treated when the server has the resources to do it."

So how I understand it is that they decrease the strain because the batch modifications are made when the server has more resources at hand.

Maybe someone with more technical knowledge could explain what happens when batch modifications are done?