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

[Bug 42580] New: 500 error for patron holds table when using group holds (DisplayAddHoldGroups)
by bugzilla-daemon＠bugs.koha-community.org 18 May '26

18 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42580 Bug ID: 42580 Summary: 500 error for patron holds table when using group holds (DisplayAddHoldGroups) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com If you place a group hold, you get a 500 error when attempting to view the patron's holds table (for both the check out and details sections). To reproduce: 1. Enable the DisplayAddHoldGroups system preference. 2. Search in the staff interface for "perl". 3. Select three items to place a hold on (for example, Programming Perl, CGI programming with Perl, Intermediate Perl). 4. Click the "Place hold" action. 5. Select a patron. 6. Tick the "Treat as hold group" option. 7. Select the pickup locations for the items. 8. Click "Place holds" 9. Go to the patrons account > Details > Holds tab. 10. You get a browser pop-up window/dialogue box with a "Something went wrong when loading the table. 500: Internal Server Error." error, and nothing is displayed in the table when you click OK (says "Loading...") 11. Console error is "DataTables warning: table id=holds-table - Ajax error. For more information about this error, please see https://datatables.net/tn/7" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 42619] New: Update various admin pages to use grid layout for forms - Part 4
by bugzilla-daemon＠bugs.koha-community.org 18 May '26

18 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42619 Bug ID: 42619 Summary: Update various admin pages to use grid layout for forms - Part 4 Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, testopia(a)bugs.koha-community.org - Administration -> Background jobs - Administration -> File transports - Administration -> New identity providers - Administration -> New identity provider domain - Administration -> Interlibrary loan batch statuses - Administration -> MARC ordering accounts -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 12029] Patrons should be able to delete their patron messages
by bugzilla-daemon＠bugs.koha-community.org 18 May '26

18 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12029 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42636 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42636 [Bug 42636] Allow dismissing patron messages via API -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42636] New: Allow dismissing patron messages via API
by bugzilla-daemon＠bugs.koha-community.org 18 May '26

18 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42636 Bug ID: 42636 Summary: Allow dismissing patron messages via API Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Depends on: 12029 Bug 12029 added the ability for patrons to dismiss message via their account in the OPAC (note this is content in the messages column, not the message_queue). We could add an API by which these messages can be dismissed via a discovery service or other third-party product. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12029 [Bug 12029] Patrons should be able to delete their patron messages -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 42607] New: Holds queue: Remove intermediate filter page now that results are API-driven
by bugzilla-daemon＠bugs.koha-community.org 18 May '26

18 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42607 Bug ID: 42607 Summary: Holds queue: Remove intermediate filter page now that results are API-driven Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Depends on: 42503 Now that the holds queue page is fully API-driven with server-side pagination, filtering, and sorting (bug 42503), the intermediate step where the user must choose a library filter before seeing results is unnecessary. The table can load immediately with all results (paginated) and the library filter can be a column filter or a dropdown above the table, like other API-driven pages. Additionally, the breadcrumbs still show a 'Results' level that no longer makes sense with the single-page approach. Changes needed: - Remove the initial filter form / two-step flow - Load the holds queue table directly on page load - Move the library filter to a table filter control - Remove 'Results' from breadcrumbs Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42503 [Bug 42503] Render the holds queue using the REST API -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 42631] New: Empty value in authorised_values_category from auth_val_cat.sql
by bugzilla-daemon＠bugs.koha-community.org 18 May '26

18 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42631 Bug ID: 42631 Summary: Empty value in authorised_values_category from auth_val_cat.sql Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com in installer/data/mysql/mandatory/auth_val_cat.sql, there is : 1 INSERT IGNORE INTO authorised_value_categories( category_name, is_system ) 2 VALUES 3 ('', 1), This leads to the existance of an empty value in concerned dropdown that does not appear to have any role in Koha. Does anyone knows what is its purpose ? Note: I'm not quite sure about the category, feel free to change -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

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

18 May '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 18

[Bug 42540] New: Trap and throw elastic too_many_clauses errors instead of just dying
by bugzilla-daemon＠bugs.koha-community.org 18 May '26

18 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42540 Bug ID: 42540 Summary: Trap and throw elastic too_many_clauses errors instead of just dying Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This started out as an issue with Connexion gateway, but it's not actually directly related. The issue is that during import, a record may contain so many fields to match on that it exceeds the max clauses an es server is configured for. In this case Koha 500's and connex emits the generic "Unsuccessful request" error. It seems the best patch forward would be to trap this error and propagate it as a Koha Exception, rather than simply die. There may be other elastic errors we could add to this pattern but I've not encountered any others so far. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 42468] New: Add systemd support for OCLC Connexion daemon
by bugzilla-daemon＠bugs.koha-community.org 18 May '26

18 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42468 Bug ID: 42468 Summary: Add systemd support for OCLC Connexion daemon Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org For some reason, connexion was never bundled into koha-common. We should add that to systemd which is added by bug 40901. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 42629] New: Capitalization: The Permitted staff only permission has no effect while this list is private.
by bugzilla-daemon＠bugs.koha-community.org 17 May '26

17 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42629 Bug ID: 42629 Summary: Capitalization: The Permitted staff only permission has no effect while this list is private. Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: Academy Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Found while translating main: The Permitted staff only permission has no effect while this list is private. The Staff only permission has no effect while this list is private. koha-tmpl/intranet-tmpl/prog/en/modules/virtualshelves/shelves.tt:74 Permitted and Staff should not be capitalized. Maybe we should use '' instead to make it clear what the name of the option is? -- You are receiving this mail because: You are watching all bug changes.

1 0