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

[Bug 29996] New: Show an alert on main page when serial issues are late
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29996 Bug ID: 29996 Summary: Show an alert on main page when serial issues are late Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Serials 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 35

[Bug 39977] New: Prevent reserves of items the users have already on their possession
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39977 Bug ID: 39977 Summary: Prevent reserves of items the users have already on their possession Change sponsored?: --- 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: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When the system preference AllowHoldsOnPatronsPossessions is set to Allow users can request holds on biblio records they have items checked out from. That includes the very items they already have in their possession. I think Koha should check at the item level that you don't already have this item. As I see this system preference, it should only allow to request a hold on the other items. For example, the bibliographic record is a manga series of several volumes. The user has checked the first volume, the system should let them to put a hold on the second volume, but not on the first one. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #196 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- (In reply to Chloé Zermatten from comment #194) > (In reply to Michaela Sieber from comment #193) > > We tested several hours and I will provide more feedback this week but here > > are the most relevant Bugs we found: > > > > 1.) Migration scenario > > > > have some overdue rule, then apply the patch and do updatabase and yarn buid > > > > Error 404 in staff interface > > > > Please see Pedros comment 192 > > > > In your testplan in comment 183 you write in > > > > Part 11: Data Integrity & Persistence > > 5. Check the database circulation_rules table: > > - Verify the overdue_X_has_rules rule kind is present > > > > Is this the missing piece for the migrated data ? > > > > > > 2.) Adding a trigger for a combination that exists in circ rules > > > > it is not possible to configure an overdue trigger with a combination that > > already exists as a circulation rule. > > > > Example to reproduce in ktd with test data: > > > > - Go to circ rules (/cgi-bin/koha/admin/smart-rules.pl) > > - Set a rule for All Libraries / All patron categories / Itemtype Books > > - Check via SQL: select * from circulation_rules > > - Go to overdue rules (/cgi-bin/koha/admin/circulation_triggers ) > > - Set a rule for All Libraries / All patron categories / All Itemtype > > - Now try to edit the delay for the applied rule > > with combination All Libraries / All patron categories / Itemtype Books > > --> Message in blue box "Your changes could not be saved as this > > circulation > > trigger was updated elsewhere. Please see the updated trigger below." > > It is not possible to save / submit > > - Now edit the delay for the applied rule > > with combination All Libraries / Patron category Homebound / Itemtype > > Books > > --> You can save without problems, if this combination does not exist in > > the database table circulation_rules > > > > > > 3.) Permissions Error if you are not an admin > > > > The Overlay rules are part of the tools and also the permission is part of > > the tools section. That means that it was enough to give users the > > edit_notice_status_triggers permission, it was not neccessary to give any > > administration permission (parameters) . > > Now you moved the overdue triggers to administration. > > > > If you now log in as a person with edit_notice_status_triggers permission > > you can see the tools module and click on the menu for overdue triggers but > > then you get the error message "Something went wrong: Error: Authorization > > failure. Missing required permission(s)." > > > > > > 4.) Edit an existing trigger does not pull delay from database > > > > Edit an existing trigger and check that the delay value is 0 , it is not > > pulled from the database. This is confusing and dangerous because you see > > the delay value just a few centimeters above in the table. > > If you save the form, the value in the database is overwritten with 0. > > > > To reproduce: follow testplan in comment 183 Part 4.3 > > Thank you for the testing and feedback, much appreciated! > > > Re - 1.) overdue_X_has_rules is a property indicating that some rule(s) > exist for a given context/trigger number combination. The most recent > version of the integration ensure it is created whenever any rule is created > for a given context/trigger number combination. The staff clients relies on > this to ascertain whether a rule set exists efficiently. > I think the solution might be to have it added to each existing > context/trigger number combination - would that be sensible? > > 2., 3., and 4.: I will do some debugging and put patches together for those, > many thanks for reporting them! Quick update on this: The latest commit (Attachment #189345) intends to address point 1, 2, and 4 from the QA feedback. 3 is, to my knowledge, one for discussion as it looks to me like expected behaviour. In the meantime, if any other bugs are found, I'll be happy to look at addressing them! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #195 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- Created attachment 189345 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=189345&action=e… Bug 10190: (follow-up) Complete Vue.js rewrite of Circulation Triggers administration interface This patch aims to resolve the following issues as reported by comment 193: - missing atomic update for overde_X_has_rules: - existing delays being overwritten by the client when a rule set is displayed - inability to save circulation overdue rule sets for context for which circulations rules where already set -- You are receiving this mail because: You are watching all bug changes.

1 0

[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