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

[Bug 33253] New: 2FA - Form not excluded from autofill
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33253 Bug ID: 33253 Summary: 2FA - Form not excluded from autofill Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: tech.sam(a)salinapublic.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I've been testing the 2FA module in our install, working great so far, but I noticed the authentication form field is not marked to be excluded from auto completion. Because of this, after several weeks of use, every time I click on the field, I see a list of all prior authentication codes used. This might be possible to be used in an attack to reverse-engineer the secret key using past codes and when they were entered. Even if that isn't the case, it means browsers are saving loads of unnecessary data that is one-time use. Information on how to disable auto completion in form fields can be found here: https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Tu… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 32092] New: Improve circulation rules cache utilization
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32092 Bug ID: 32092 Summary: Improve circulation rules cache utilization 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 Currently the cache is bypassed when fetching of circulation rules in a lot of places, calling get_effective_rule instead of get_effective_rule_value which makes use of in-memory cached. Additionally the case where the rule value is an empty string or undefined or no rule is found are not currently cached which results in the database is being queried repeatedly for cases where no results are found (which usually are the majority of calls). For example on the page where items are listed when placing a hold the current hit ratio for the cache in get_effective_rule_value is about 6%, with this patch we instead get a hit ratio of 99.8%, resulting in a whooping 340x less time spent performing the database lookup in get_effective_rule_value. With 150 items (we have serials with up to 1400 items), about 50% of the execution time is spent looking up rules which is practically reduced to zero when also caching empty results (and replacing the uncached direct calls to get_effective_rule with get_effective_rule_value). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 55

[Bug 34756] New: Cancelling a hold does not cancel the related transfer
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Bug ID: 34756 Summary: Cancelling a hold does not cancel the related transfer Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When a hold is confirmed and its pickup location is different from the item's location, a transfer is initiated. If the hold is cancelled, the item remains in transfer whereas it is no longer needed at the transfer destination. Is this normal behaviour ? It seems that staff users should at least see a message about the transfer and maybe have the ability to cancel it. Steps to reproduce: 1. Create an item at library A 2. Place a hold on this item with a pickup location at library B 3. Check in the item at library A 4. Confirm the hold. The item should now be in transit to library B 5. Cancel the hold. There is no message about the probably useless transfer. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 38291] New: Add GET /library_groups
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38291 Bug ID: 38291 Summary: Add GET /library_groups Change sponsored?: --- 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: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com We should have an endpoint to list library groups -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 55

[Bug 28183] New: retain patron-deleted suggestions
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28183 Bug ID: 28183 Summary: retain patron-deleted suggestions Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In the purchase suggestions process, when a patron deletes their suggestion, the data is gone from all elements. For instance, a patron makes a purchase suggestion, the library orders the item and notifies the patron it has been ordered, if the patron then deletes the suggestion, there is no record/information for the library about who wanted it, etc. It is completely removed from the purchase suggestion process. This is information that libraries need to be able to view, even if it is only available via reports on deleted tables or something. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 40736] New: OAuth/OIDC authentication broken when CGISESSID is missing
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40736 Bug ID: 40736 Summary: OAuth/OIDC authentication broken when CGISESSID is missing Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Our API error logs contain multiple instances of the following error > [ERROR] Can't call method "value" on an undefined value at /usr/share/koha/lib/Koha/REST/V1/OAuth/Client.pm line 100. Client.pm:100 is > $state = Koha::Token->new->generate_csrf( { session_id => $c->req->cookie('CGISESSID')->value } ); This happens when a web crawler (Googlebot in our case) navigates to OAuth/OIDC login API endpoint, and Koha attempts to generate them a new CSRF token but is unable to due to missing CGISESSID cookie. To replicate: 1. Have an identity provider <provider code> defined under Administration > Identity providers 2. On a fresh browser session (clear cookies), 3. Navigate to https://yourkoha/api/v1/public/oauth/login/<provider code>/opac 4. Observe [ERROR] Can't call method "value" on an undefined value at /usr/share/koha/lib/Koha/REST/V1/OAuth/Client.pm line 100. in plack-api-error.log -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 40824] New: Add option to prevent re-use of passwords
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '26

18 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40824 Bug ID: 40824 Summary: Add option to prevent re-use of passwords Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: jacob.omara(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org This feature would prevent you from reusing the last X number of passwords at password change. Would be controlled at system level but also with patron category level overrides for the default. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 66

[Bug 19838] New: Add system preference for adding text to self registration form
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '26

17 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19838 Bug ID: 19838 Summary: Add system preference for adding text to self registration form 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Some libraries would like to add some explanations to the self registration form. At the moment there is only a system preference for the page that shows after submitting the registration form. It would be helpful to have another that shows on the self registration form itself. -- You are receiving this mail because: You are watching all bug changes.

1 45

[Bug 40290] New: a german string in a source file
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '26

17 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40290 Bug ID: 40290 Summary: a german string in a source file Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: e.betemps(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de Hi, translating strings on Weblate, I found a sentence in german here is the link on Weblate : https://translate.koha-community.org/translate/koha-manual/valuebuilder/fr/… the file is : https://gitlab.com/koha-community/koha-manual/-/blob/main/source/images.rst… here is what il looks like (in the file) : .. |image1518| image:: images/cataloging/cn_browser_value_builder.png :alt: Signaturenbrowser in Unterfeld o von Feld 952 anschließen -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 23054] New: Unable to change priority after reverting hold waiting status
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23054 Bug ID: 23054 Summary: Unable to change priority after reverting hold waiting status Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- To Test: - Place a hold for Patron A - Place a hold on same item for Patron B - Check item in, triggering Patron A's hold - Revert waiting status on hold - Confirm holds list shows Patron A at priority 1, Patron B at priority 2 - Use arrow buttons to move Patron B to priority 1 - Query reserves table to confirm Patron B at priority 1, Patron A at priority 2 - Check item in - Patron A's hold triggers, even though Patron B was first in priority -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2