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

[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 43139] New: ILL requests Widget should sort desc to display newest records
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43139 Bug ID: 43139 Summary: ILL requests Widget should sort desc to display newest records Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- Test plan: Prerequisites Ensure that there are more than 5 ill requests (borrowing) in the system. Steps to Reproduce Go to koha/ill/home Actual Result The first five records are displayed in the results list, the list is ordered by ID asc Expected Result The newest records should be displayed, list should be ordered by ID desc -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[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 41608] New: Ability to select multiple values of a facet in the professional interface
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41608 Bug ID: 41608 Summary: Ability to select multiple values of a facet in the professional interface Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In the professional interface, we should be able to select several values from a facet in a single operation (e.g., several libraries, several languages, etc.), so that Koha applies the "OR" operator between each value (e.g., return documents present in library A or library B) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 97

[Bug 43849] New: Add context for translation of "Editor"
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43849 Bug ID: 43849 Summary: Add context for translation of "Editor" Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: caroline.cyr-la-rose(a)inlibro.com, f.demians(a)tamil.fr, jonathan.druart(a)gmail.com, julian.maurice(a)biblibre.com Target Milestone: --- The word "Editor" can be translated in different ways. In MARC frameworks it refers to bibliographic record's editor, the page where you edit the record. koha-tmpl/intranet-tmpl/prog/en/modules/admin/marc_subfields_structure.tt:238 • koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/editor.tt:36 In other places it can refer to a person or an occupation. We need to use different translations for these different use cases so it would be nice to have context for these translations. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43847] New: SessionRestrictionByIP: Session cookie not properly shared between opac and backend when using a proxy
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43847 Bug ID: 43847 Summary: SessionRestrictionByIP: Session cookie not properly shared between opac and backend when using a proxy Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: cornelius.hertfelder(a)bsz-bw.de QA Contact: martin.renvoize(a)openfifth.co.uk CC: dpavlin(a)rot13.org Target Milestone: --- Hello, we observes a strange bug when using Anubis as anti-crawler measure and running Kohas backend on port 8080 as default. Anubis (port 443) RequestHeader set X-Forwarded-Proto "https" RequestHeader set X-Forwarded-Port "443" RequestHeader set X-Forwarded-Host expr=%{HTTP_HOST} RequestHeader set X-Forwarded-For expr=%{REMOTE_ADDR} RequestHeader set X-Real-Ip expr=%{REMOTE_ADDR} Koha (port 80) RemoteIPHeader X-Forwarded-For RemoteIPInternalProxy 127.0.0.1 Intranet / backend is directly accessible without proxy (Port 8080). the backend is protected by firewall so we don't need Anubis here. Before we used Anubis the following worked for years: 1. Login to backend 2. go to opac 3. see you're logged in in the OPAC as well. 4. still logged in into backend Now the behavior is as folows 1. Log in to backend 2. go to OPAC 3. not logged in in OPAC 4. Being immediatelly logged out of backend This is caused by the CGISESSID cookie not transfered in the initial request to Anubis / Koha. A workaround is to disable the SessionRestrictionByIP. This leads us to the trusted proxies. Koha should trust the reverse proxies IP and then use the X-Forwarded-For header instead of REMOTE_ADDR. Then, the OPAC behind Anubis should see the same IP as the backend which is directly accessible. We further investigated this but setting trusted_proxies to 127.0.0.1 does not change the behavior. Same same for setting up a botpolicy which will automatically allow clients without challenge. The requests are then still proxies and this causes the problem. I guess there is something missing and some code still uses remote IP. Or trusted proxies is implemented in a way that enforces the X-Forwarded-For header for the backend, too, which is not available here. Hope this will be an easy pick. Cornelius -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[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 42862] New: bookingsModalDatePicker_spec.ts is failing
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42862 Bug ID: 42862 Summary: bookingsModalDatePicker_spec.ts is failing Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The file bookingsModalDatePicker_spec.ts has a test that checks a booking calendar using hardcoded June 2026 dates, faking "today" as 2026-06-01 so those dates look like the future. That fake date is lost when the test reloads the page midway through, so the real date takes over causing it to fail. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 42928] New: In viewlog.tt #actionRETURN should be Retrun, not Check-in
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42928 Bug ID: 42928 Summary: In viewlog.tt #actionRETURN should be Retrun, not Check-in Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 42131 updated the terminology in the table. We should also update the label for the #actionRETURN checkbox to be "Retrun". -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 43846] New: Patron search only matches authorised value codes instead of displayed descriptions
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43846 Bug ID: 43846 Summary: Patron search only matches authorised value codes instead of displayed descriptions Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: gehim+kohabugzilla(a)posteo.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Description When searching for patrons using an extended patron attribute linked to an authorised value category, the search only matches the internal authorised value code instead of the description displayed to staff users. This makes searching confusing, as staff members normally only see and select the description, while the internal code is not readily visible after configuration. Steps to reproduce: Create an authorised value category named SCHOOLCLASS with the following entries: Authorised value - Description 1A - 1a 1B - 1b 99 - Unknown Create a patron attribute type: Code: SCHOOL_CLASS Description: School class Authorised value category: SCHOOLCLASS Edit a patron record and select Unknown as the value for School class. Open the patron search in the staff interface and search using the School class attribute. Search for Unknown. Repeat the search using 99. Actual result: Searching for Unknown returns no matching patrons. Searching for 99 returns the expected patrons. Expected result: Searching for Unknown should return all patrons whose School class attribute displays Unknown. Ideally, searching by either the authorised value code or its description should return matching patrons. Why this is a problem: Staff members select and see the description (Unknown) when editing or viewing patron records. However, the search requires the underlying authorised value code (99), which is not readily visible in normal patron workflows. This behaviour is unintuitive and makes the search difficult to use without knowledge of the internal configuration. Related issue: See also Bug 15337 and Bug 21026 for similar issues involving internal codes versus displayed descriptions in other parts of Koha. Environment: Koha version: 26.05.03 MariaDB version: 11.8.6 Interface: Staff client -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0