May 2026 - Koha-bugs - lists.koha-community.org

[Bug 42373] New: Add ability to disallow unbounded patron api searches
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42373 Bug ID: 42373 Summary: Add ability to disallow unbounded patron api searches Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com In a Koha instance with multiple hundreds of thousands of patrons, a patron api search with _per_page=-1 can cause a single worker to query the database for all patrons, then query the database multiple times for each of those patrons to decorate the resulting patrons ( fees owed, etc ). If the _per_page size is greater than the limit we specify, Koha should refuse the request and emit an http status code 400, with a clear error body explaining the max allowed _per_page value. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 42108] New: Add ability to specify that a report can only be run as a foreground or background report
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42108 Bug ID: 42108 Summary: Add ability to specify that a report can only be run as a foreground or background report Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Building on bug 41921, it would be useful to be able to specify a report can only run as a background report for long-running reports. For the sake of completeness, we could also add the ability to specify reports as being foreground-only reports as well. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 41048] New: Add ability to disallow empty patron searches
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41048 Bug ID: 41048 Summary: Add ability to disallow empty patron searches Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com In high traffic environments with large numbers of patrons, empty patron searches can take a very long time and cause over-use of resources. It would be good to have the option to require search criteria for patron searches. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 57

[Bug 38963] New: Deletion of bibliographic record can cause search errors in OPAC
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38963 Bug ID: 38963 Summary: Deletion of bibliographic record can cause search errors in OPAC Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Same has Bug 37425 for OPAC search Bug 35558 added a check to see if the associated biblio has local cover images, however, when a biblio is deleted there is a delay in the background job reindexing the biblio. This can lead to 500 errors when a search retrieves the biblio before it has been removed from the index. -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 37425] New: Deletion of biblio can cause search errors
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37425 Bug ID: 37425 Summary: Deletion of biblio can cause search errors Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 35558 added a check to see if the associated biblio has local cover images, however, when a biblio is deleted there is a delay in the background job reindexing the biblio. This can lead to 500 errors when a search retrieves the biblio before it has been removed from the index. To recreate: 1 - Enabled system preference LocalCoverImages 2 - Perform a search in staff interface 3 - Find the biblionumebr for one of the results and delete it via the SQL backend: DELETE FROM biblio WHERE biblionumber=3; 4 - Search again. 5 - KO! Can't call method "cover_images" on an undefined value at /usr/share/koha/intranet/cgi-bin/catalogue/search.pl line 671. 6 - Reindex, confirm error is gone -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 23649] New: Elasticsearch offer an option to weight search results by type
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23649 Bug ID: 23649 Summary: Elasticsearch offer an option to weight search results by type Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com Some libraries would like to be able to prioritize "books" over "large print" , audios, etc in the search results -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 35484] New: OPACShelfBrowser secondary sort should be biblio.title not item.itemnumber
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35484 Bug ID: 35484 Summary: OPACShelfBrowser secondary sort should be biblio.title not item.itemnumber Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The OPACShelfBrowser sorts on cn_sort but also includes a secondary sort on itemnumber. This secondary sort is arbitrary and unhelpful, libraries typically don't arrange things on the shelf based on Koha's itemnumber. This secondary sort should be based on title to better refelct how libraries organize shelves. To recreate: 1. In k-t-d, set all item itemcallnumbers to the same thing, ie: 'abcdefg'; 2. Touch all items to update the cn_sort values 3. Turn on OPACShelfBrowser and view a record detail page on the OPAC. 4. Browse the shelf and see that all items are organized by itemnumber. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 40589] New: Add table settings to recalls pages
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40589 Bug ID: 40589 Summary: Add table settings to recalls pages Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com I propose to add table settings to these pages: - Recalls queue - Recalls to pull - Overdue recalls - Recalls awaiting pickup - Old recalls -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 42504] New: Remove totalissues from stored MARC, embed at index time
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42504 Bug ID: 42504 Summary: Remove totalissues from stored MARC, embed at index time Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org ## Problem update_totalissues.pl can run for 4+ hours on large installations. The root cause is that totalissues is stored in the MARC record (942$0), requiring the full ModBiblio pipeline per biblio: MARC XML deserialization, field update, serialization, TransformMarcToKoha, DB updates, search engine reindexing, cataloguing log entries, plugin hooks, OAI sets updates. The existing UpdateTotalIssuesOnCirc syspref provides real-time updates on checkout but is disabled by default because it triggers this same expensive ModBiblio pipeline on every checkout. Bug 36474 improved things by skipping unchanged records, but every changed record still pays the full cost. ## Proposal Stop storing totalissues in the MARC record. Instead: 1. UpdateTotalIssues becomes a lightweight DB-only operation: just UPDATE biblioitems SET totalissues = ? WHERE biblionumber = ? plus queue a search index update. No MARC parsing, no ModBiblio. 2. Inject 942$0 at index time via Koha::Biblio::metadata_record: Add an embed_total_issues parameter (following the existing embed_items pattern). Both search engine indexers call metadata_record to get the MARC before indexing. The value gets injected from biblioitems.totalissues on the fly, just like items are embedded today. The stored MARC in biblio_metadata stays clean. Both the ES indexer (_get_record) and Zebra's rebuild_zebra.pl -d (which already pre-processes records before sending to Zebra) would pass this flag. 3. UpdateTotalIssuesOnCirc becomes cheap enough to enable by default: A DB column update plus a reindex queue entry per checkout is trivial. The Elasticsearch indexer already batches indexing tasks efficiently. 4. update_totalissues.pl is simplified: It recalculates biblioitems.totalissues from statistics/items data and triggers batch reindexing. It no longer touches MARC records at all. It should also gain a --commit option to control batch sizes for the reindex step. ## Expected impact - Real-time totalissues updates on checkout with negligible performance cost - update_totalissues.pl runtime reduced from hours to minutes (DB updates + batch reindex vs per-record ModBiblio) - No more MARC record churn for a derived counter value - Reduced action_logs noise (no cataloguing log entries for counter updates) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 37344] New: Patrons with cancelled discharge are seen as discharged when suspended due to overdue
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37344 Bug ID: 37344 Summary: Patrons with cancelled discharge are seen as discharged when suspended due to overdue Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org GIVEN: 1 - A library with overdue suspension 2 - A user with a cancelled discharge 3 - The same user has an issue whose date_due is gone WHEN: 1 - The book is checked in 2 - The user connects to the OPAC THEN: The user can see they are suspended due to a discharge EXPECTED: The user can see they are suspended due to an overdue -- You are receiving this mail because: You are watching all bug changes.

1 73