May 2026 - 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 42385] New: Extract _GetCircControlBranch into Koha::Policy::Circulation
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42385 Bug ID: 42385 Summary: Extract _GetCircControlBranch into Koha::Policy::Circulation 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 Depends on: 41728 _GetCircControlBranch is a private function in C4::Circulation that is exported (the code itself comments "This is wrong!") and used from Koha::Item, Koha::Recall, and multiple places in C4::Circulation. It resolves which library controls circulation rules given the CircControl and HomeOrHoldingBranch system preferences. This is the exact same pattern as Koha::Policy::Holds->holds_control_library, which resolves the controlling library for hold rules based on ReservesControlBranch. This bug proposes: - Add Koha::Policy::Circulation with a circ_control_library($item, $patron) class method - Replace all _GetCircControlBranch calls with the new method - Remove the exported private function from C4::Circulation - Add unit tests This is a prerequisite for the checkout availability work, as the future Koha::Item::Checkout::Availability class would need to resolve the controlling library. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41728 [Bug 41728] Add `Koha::Item::Checkin::Availability` to centralize logic -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 43

[Bug 42396] New: Replace C4::Stats::UpdateStats calls with Koha::Statistic->store
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42396 Bug ID: 42396 Summary: Replace C4::Stats::UpdateStats calls with Koha::Statistic->store Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 19871 C4::Stats::UpdateStats is a trivial legacy wrapper that just calls Koha::Statistic->new($params)->store. All callers should use the Koha::Statistic object directly instead of going through the C4 shim. Callers to update: - Koha::Item::_add_statistic - C4::Circulation - C4::Accounts - Koha::Account - Koha::Recalls - Koha::ILL::Request Once all callers are migrated, C4::Stats can be removed entirely. Identified during QA review of bug 19871. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19871 [Bug 19871] Use new exceptions Koha::Exceptions::Object::DuplicateID and FKConstraint -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[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 42577] New: Gettext.js incorrectly located and tidied
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42577 Bug ID: 42577 Summary: Gettext.js incorrectly located and tidied Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If you look at opac-tmpl/bootstrap/js/Gettext.js or its intranet-tmpl equivalent, you'll notice that it's actually a third-party script and not a Koha script, so it should be in the "lib" folder and the license for it should be added to about.tt We've also tidied the file because it wasn't in "lib"... so we might want to undo that. -- You are receiving this mail because: You are watching all bug changes.

1 10

[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 42596] New: Add ability for reports APIs ( svc/report, opac/svc/report ) to run reports as background jobs
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '26

18 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42596 Bug ID: 42596 Summary: Add ability for reports APIs ( svc/report, opac/svc/report ) to run reports as background jobs 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 Right now, all svc reports act as "foreground" jobs and return data immediately. This can cause issues such as apache timeouts for long running jobs. It would make sense to have the ability for a caller to ask for a background job and be given an id so that it can a) look up the status of the job ( waiting, running, finished, failed ) and if the job is finished, b) download the results of the report. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[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