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

[Bug 34142] New: Add column sub_location to items table
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34142 Bug ID: 34142 Summary: Add column sub_location to items table 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: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org We should add new column sub_location to items and deleteditems table. This can be used to indicate e.g. if item has some other more specific location than permanent location. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 55

[Bug 43397] New: SIP accounts with a blank AE field template send an empty patron name
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43397 Bug ID: 43397 Summary: SIP accounts with a blank AE field template send an empty patron name Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 37893 moved SIP accounts from SIPconfig.xml into the database. The new SIP account editor initializes every text field to an empty string rather than null, so an account created through the staff interface gets ae_field_template = '' instead of NULL which is defined and so the empty template is used thus giving an empty AE field in responses for newly created accounts! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 43727] New: SIP no block checkouts and offline checkouts leave another patron's waiting hold in place
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43727 Bug ID: 43727 Summary: SIP no block checkouts and offline checkouts leave another patron's waiting hold in place Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When a SIP2 client sends a checkout with the no block flag set to Y, Koha has to accept it, so the checkout skips every check and goes through ProcessOfflineIssue. ProcessOfflineIssue calls AddIssue without a cancelreserve value, so a hold that is waiting, in transit, or in processing for a different patron is left alone. The item ends up checked out to one patron while it is still on another patron's holds waiting list. The hold sits there until it expires off the hold shelf, so the patron who placed it never gets the item. When staff check out an item with a waiting hold in the staff interface, Koha defaults to reverting the hold's waiting status. No block and offline checkouts should do the same, so the hold goes back to the top of the queue and is filled by the next copy. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 38181] New: Extreme slow search results on OPAC (only) search when result records contain multiple items.
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38181 Bug ID: 38181 Summary: Extreme slow search results on OPAC (only) search when result records contain multiple items. Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: kdask(a)altsol.gr QA Contact: testopia(a)bugs.koha-community.org When performing a search on the OPAC, if the results containing records that are having a large number of holdings (e.g serials with over 1000 issues/items or even less) there is a huge delay on showing the results (~x8 times slower for the same search if we remove the multiple items from the resulting records) The odd is that the exact same search on the intranet interface works without these delays so I'm guessing that this is a problem on the OPAC search implementation? The problem exists with zebra but also with the use of Elasticsearch engine. Using elasticsearch tried also removing all the item related indexes - 952* subfields (and re-indexing) but the result is the same. In the following google drive link you can find a demo bib record with 1809 items (MarcXML - Marc21) if it helps to reproduce it.https://drive.google.com/file/d/11SQmfdWal9tzcovS0mrgu6vIOPf1aCbc/view You will have to import the record, and then try searching for the title on OPAC: The Journal of biological chemistry. In my case with a decent server without load (Debian, 4cpu cores, 16gb RAM) with plack enabled takes about ~50sec to get the result. Regards -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 49

[Bug 43786] New: Incorrect string concat in templates
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43786 Bug ID: 43786 Summary: Incorrect string concat in templates Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 41340 Target Milestone: --- From 41340 comment 12 + >[% tnx( '{count} item modified', '{count} items modified', modified_items_count, { count = modified_items_count }) + ' (' + tnx( 'with {count} field modified', 'with {count} fields modified', modified_fields_count, { count = modified_fields_count }) + ').' | html %]</span String concat with TT is with "_", not "+" [2026/09/30 07:56:36] [WARN] Argument " (" isn't numeric in addition (+) at /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/en/includes/background_jobs/batch_item_record_modification.inc line 19. [2026/09/30 07:56:36] [WARN] Argument "3 items modified" isn't numeric in addition (+) at /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/en/includes/background_jobs/batch_item_record_modification.inc line 19. [2026/09/30 07:56:36] [WARN] Argument "with 3 fields modified" isn't numeric in addition (+) at /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/en/includes/background_jobs/batch_item_record_modification.inc line 19. [2026/09/30 07:56:36] [WARN] Argument ")." isn't numeric in addition (+) at /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/en/includes/background_jobs/batch_item_record_modification.inc line 19. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41340 [Bug 41340] Better translatability on 'batch_item_record_modification.inc' -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 42274] New: opac-tags.pl should return JSON instead of JS script
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42274 Bug ID: 42274 Summary: opac-tags.pl should return JSON instead of JS script Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org koha-tmpl/opac-tmpl/bootstrap/js/tags.js makes AJAX calls to ./opac/opac-tags.pl which returns Javascript scripts rather than JSON. The crazy part is that it's mostly just returning a JSON object anyway. There are some gotchas where it returns a JS object with embedded KOHA.Tags.tag_message() functions, but I'm sure we can fix that. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 43654] New: Item search: DataTables column filters ignored when 2+ conditions are combined (follow-up to Bug 36930)
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43654 Bug ID: 43654 Summary: Item search: DataTables column filters ignored when 2+ conditions are combined (follow-up to Bug 36930) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface 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 Target Milestone: --- Bug 36930 fixed item search returning wrong results when 2+ added conditions were combined, by making the filter constructor in catalogue/itemsearch.pl detect whether parameters arrived as 'f[]' (bracket notation, sent by JS when there are 2+ conditions) or plain 'f' (single condition), and read/write consistently. However, the JSON-preprocessing block that merges DataTables column filters (free-text search box and dropdowns for library, item type, etc. in the results table) still unconditionally reads from multi_param('f') without brackets. With 2+ conditions, that call returns empty (JS sent 'f[]'), so the column filters get pushed onto an empty array and written back to the plain 'f' param — which the filter constructor further down (fixed by Bug 36930) never reads, since it's looking at 'f[]'. The column filters are silently ignored and the results table gets stuck on "Processing". Steps to reproduce: 1. Go to Cataloging > Item search. 2. Add 2 search conditions (e.g. Library = X AND Item type = Y). 3. Run the search, then try to filter further using one of the result table's column filters (e.g. type a value in a free-text column filter, or pick a value from a dropdown column filter). 4. The column filter has no effect / the table stays on "Processing". With only 1 condition, column filters work correctly. Fix: read/write the same 'f[]'/'q[]'/'op[]'/'c[]' vs 'f'/'q'/'op'/'c' convention in the preprocessing block, detected the same way the Bug 36930 filter constructor already does (checking for the bracketed param name among $cgi->multi_param). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 43671] New: Holds impair SCO module load time
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43671 Bug ID: 43671 Summary: Holds impair SCO module load time Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Self checkout Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- In a large system, holds can have a significant impact on the amount of time it takes for the main page to load in the SCO module. In our system during busy times, patrons with many holds see load times of 20 seconds or more after logging into the SCO Module and after each checkout. We can already avoid the impact of existing checkouts on SCO Module load times, because the system preference SCOLoadCheckoutsByDefault allows the patron's existing checkouts to be loaded on-demand. We should have the option to delay the loading of holds as well. -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 43623] New: Pagination of JSON Report Exports
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43623 Bug ID: 43623 Summary: Pagination of JSON Report Exports Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Target Milestone: --- To avoid the risk of downloading too many rows when exporting a report as JSON, I wanted to try paginating the results by adding a limit and a variable offset (a parameter passed in the URL) to the report. But OFFSET doesn’t seem to be supported in SQL, which surprises me because it isn’t listed among the filtered keywords specified in the community wiki (create, update, etc.). Example: select itemnumber from items LIMIT 50 OFFSET 100 gives me : You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'LIMIT 0, 50' at line 2 Is it a bug ? a missing feature? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 43831] New: Patron duplicate check matches every new patron when an existing patron is blank in all compared fields
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43831 Bug ID: 43831 Summary: Patron duplicate check matches every new patron when an existing patron is blank in all compared fields Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: nugged(a)gmail.com Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Since bug 42018, a field that is blank in an existing patron record no longer stops that record from being reported as a possible duplicate: each field in PatronDuplicateMatchingAddFields is checked as "same value, or blank in the existing record". As a side effect, an existing patron that is blank in every compared field now matches every new patron, as long as at least one configured comparison field is supplied (requests with no usable comparison values keep the bug 43069 guard). With the default PatronDuplicateMatchingAddFields (surname|firstname|dateofbirth), one record without surname, first name and date of birth (for example an account created with only a card number or a user name) is offered as the duplicate of every new patron: - staff interface: Patrons > New patron always shows "Duplicate patron record?"; - OPAC self registration reports a possible duplicate; - POST /api/v1/patrons answers 409 "A patron record matching these details already exists" unless the x-confirm-not-duplicate header is sent. Steps to reproduce: 1. Go to Administration > System preferences, search for BorrowerMandatoryField, remove "surname" (keep "cardnumber") and save. 2. Make sure PatronDuplicateMatchingAddFields is "surname|firstname|dateofbirth". 3. Go to Patrons > New patron, choose category "Patron" (or any adult category without age limits), leave Surname, First name and Date of birth empty, fill in Card number and Library, and save. 4. Go to Patrons > New patron again, choose the same category, fill in Surname "Doe", First name "Jane", Date of birth 05/05/1990, a Card number and a Library, and save. Expected result: The new patron is saved. A record that has none of the compared fields filled in cannot be a duplicate of anyone. Actual result: "Duplicate patron record?" is shown and the patron created in step 3 is offered as the existing record. The same happens for otherwise unrelated new patrons, whatever their name and date of birth. Technical note: Koha::Patrons->check_for_existing_matches builds AND(field = value OR field is blank) over the compared fields. When every compared field is blank in an existing record, all conditions are true. Partially blank records should keep matching as bug 42018 intended, but at least one compared field should hold the same value. See also bug 42018 and bug 40082. -- You are receiving this mail because: You are watching all bug changes.

1 15