October 2025 - Koha-bugs - lists.koha-community.org

[Bug 36569] New: Compact action_logs indicies
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36569 Bug ID: 36569 Summary: Compact action_logs indicies Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org With cataloguing logging enabled on the action_logs table it will become large. The module and action columns in action_logs are MEDIUMTEXT (max ~16 million bytes) with 196 first characters used for the index. Since these columns holds names that are only used programatically we could reduce the size of these columns to make the index more compact. Since module and action is often used together we can instead create a combined index and still have a smaller table. > SELECT module, action, count(*) FROM action_logs GROUP BY module, action; +------------------+----------------+----------+ | module | action | count(*) | +------------------+----------------+----------+ | CATALOGUING | ADD | 543638 | | CATALOGUING | DELETE | 573712 | | CATALOGUING | MODIFY | 6264928 | . . . | SYSTEMPREFERENCE | MODIFY | 554 | +------------------+----------------+----------+ 33 rows in set (6 min 49,652 sec) -rw-rw---- 1 mysql mysql 27439136768 10 apr 16.45 action_logs.ibd -rw-rw---- 1 mysql mysql 24368906240 10 apr 17.33 action_logs.ibd (/ (- 27439136768 24368906240) 27439136768.0) (/ (- 27439136768 24914165760) 27439136768.0) Changing the column sizes to 30 bytes each reduce the size of the action_logs table by 11%. > ALTER TABLE action_logs MODIFY COLUMN module VARCHAR(30) CHARSET ascii, MODIFY COLUMN action VARCHAR(30) CHARSET ascii; Query OK, 8725398 rows affected (18 min 32,541 sec) Records: 8725398 Duplicates: 0 Warnings: 0 After creating a combined index the size is still 9% less than before: CREATE INDEX IF NOT EXISTS module_action_idx ON action_logs(module, action); Performance improvement 22024%: +------------------+----------------+----------+ | module | action | count(*) | +------------------+----------------+----------+ | CATALOGUING | ADD | 543638 | | CATALOGUING | DELETE | 573712 | | CATALOGUING | MODIFY | 6264928 | . . . | SYSTEMPREFERENCE | MODIFY | 554 | +------------------+----------------+----------+ 33 rows in set (1,860 sec) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 32055] New: Remove GetImportRecordMatches
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32055 Bug ID: 32055 Summary: Remove GetImportRecordMatches Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 32054 removes most uses, we should finish the job -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 36437] New: Add publication year facet to Elasticsearch
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36437 Bug ID: 36437 Summary: Add publication year facet to Elasticsearch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: schodkowy.omegi-0r(a)icloud.com Reporter: schodkowy.omegi-0r(a)icloud.com Similarly to Bug 18213, it'd be nice to add publication date facet. It seems to work quite nicely, so why not? Our librarians say it's super useful. I've seen one library implement it in their fork, the only difference is that they sort the publication year facet in reverse incremental order (so from newest to oldest year instead of oldest to newest), but I think this would require an explicit check in the code, and I wasn't sure if that'd be fine... To test, one should have Elasticsearch enabled and re-generate the mappings from file and reindex as described in Bug 18213. Then confirm that the facet is visible and working: - in OPAC search - in intranet search - in intranet settings, under Elasticsearch mapping settings page, biblio tab, publication year facet should be visible at the bottom where you set facet order, with correct label; you should be able to change the order normally as expected -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 32476] New: Add caching for relatively expensive patron methods
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32476 Bug ID: 32476 Summary: Add caching for relatively expensive patron methods Change sponsored?: --- Product: Koha Version: master 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: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Add caching for is_expired and has_overdues in Koha::Patron, since these are accessed a lot and involves some database and datetime-operations that really only needs to be evaluated once per patron object it adds up to quite a lot in some use cases (where patrons have a significant amount of checkouts). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 68

[Bug 28173] New: Add plugin hooks object_store_pre and object_store_post
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28173 Bug ID: 28173 Summary: Add plugin hooks object_store_pre and object_store_post Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 35899] New: Performance improvements for build_holds_queue
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35899 Bug ID: 35899 Summary: Performance improvements for build_holds_queue Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com On a large and busy system the holds queue can take several minutes to build adding a significant load to the database and koha server. I have profiled the script and have noticed two major inefficiencies: 1. Calls to C4::Circulation::GetBranchItemRule constitute roughly 35% of the runtime. But this method can easily be memoized. 2. With LocalHoldsPriority enabled, expensive checks are made for all available items, even if it is only relevant to do these checks for local items. Depending on how the system is configured, either the unnecessary loading of patron objects, or calls to _checkHoldPolicy can take considerable time. I have prepared two patches which together cuts the runtime of the script with abouth 50% if LocalHoldsPriority is enabled. Profiling result before: https://bv-test-opac.biblioteket.nu/resources/before/index.html Profiling result after: https://bv-test-opac.biblioteket.nu/resources/after/index.html -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 37743] New: MARC21 810$t is used in XSLT templates but is not editable by default
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37743 Bug ID: 37743 Summary: MARC21 810$t is used in XSLT templates but is not editable by default Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: olli-antti.kivilahti(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl XSLT-template in question: intranet/htdocs/intranet-tmpl/prog/en/xslt/MARC21slimUtils.xsl Field 810$t is used to populate a search query, so it looks pretty important: <a><xsl:attribute name="href"><xsl:value-of select="$searchurl"/>?q=se,phr:"<xsl:value-of select="str:encode-uri(marc:subfield[@code='t'], true())"/>"&q=au:"<xsl:value-of select="str:encode-uri(marc:subfield[@code='a'], true())"/>"</xsl:attribute> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 37201] New: Add a syspref to allow or not a checkout if a expired booking exists for the same patron
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37201 Bug ID: 37201 Summary: Add a syspref to allow or not a checkout if a expired booking exists for the same patron Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hello :) I've worked on a way to prevent checkout to patron if this same patron has a booking expired for the same item.. I think it's a setting that might not suit everyone, so I've introduced a new system preference. I'll put my patch in place and await your comments. Thanks ^^ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 37885] New: Add ability to disable message queue processing
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37885 Bug ID: 37885 Summary: Add ability to disable message queue processing Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org There exist services that libraries utilize as an alternative to processing the message queue. These services may utilize the queued messages and send them from outside of Koha. Sometimes these services utilize the API or reports while other times they utilize a plugin. It would be beneficial to be able to disable running the message queue processor altogether, or to only execute the plugin hook related to message queue processing ( before_send_messages ) to limit the processing of messages to those handled by plugins. I think a new system preference along the lines of "Process/Don't process/Process only via plugins" would be good, but haven't quite come up with a sentence that makes sense. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 37359] New: Advanced editor should work with unimarc
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37359 Bug ID: 37359 Summary: Advanced editor should work with unimarc Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In the manual I read for EnableAdvancedCatalogingEditor : "This feature does not currently include any support for UNIMARC or NORMARC fixed fields." Is it true? If so, it could be an improvement to make this feature available for UNIMARC installs -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4