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

[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 14 Oct '26

14 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 14

[Bug 36644] New: Add option for 'Holds per item group' to circulation rules
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36644 Bug ID: 36644 Summary: Add option for 'Holds per item group' to circulation rules 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: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Not sure if this was a staff interface or hold request bug, so took a stab at it. We need a bit more granularity to hold policy on circulation rules for libraries using item group holds. Currently, libraries can only specify 'holds per record' in circulation rules, which is not a one-size-fits-all-holds solution - if they generally only want patrons to have one hold on a record for, say, books, but their manga collection is also a book item type, they have to set Holds per record (count) to a high or unlimited threshold to accommodate group holds. It would be great if circ rules could indicate a limit to holds per item group to give libraries flexibility in using item groups; many libraries probably only want one hold per item group, but they may have a collection where patrons can make multiple requests per group. Circ rules are a logical place to set this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

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

14 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 40

[Bug 43811] New: Patron attribute types not sustainable across libraries
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43811 Bug ID: 43811 Summary: Patron attribute types not sustainable across libraries Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- If a patron has a patron attribute type value that is limited to specific libraries, and another library that is not allowed to assign that value updates that patron without touching that attribute, they are forced to change the attribute. Values that are limited to specific branches should be sustainable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43073] New: Update MARC21 default framework to Update 42 (May 2026)
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43073 Bug ID: 43073 Summary: Update MARC21 default framework to Update 42 (May 2026) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- https://loc.gov/marc/bibliographic/bdapndxg.html ■ New content designators: Indicator 2ndPresence of accessibility features/hazards in 341 (Accessibility Content) Indicator values #No information provided in 341 (Accessibility Content) 2nd indicator: Presence of accessibility features/hazards 1Accessibility features present in 341 (Accessibility Content) 2nd indicator: Presence of accessibility features/hazards 2No accessibility features present in 341 (Accessibility Content) 2nd indicator: Presence of accessibility features/hazards 3Sensory hazards present in 341 (Accessibility Content) 2nd indicator: Presence of accessibility features/hazards Subfields $h Sensory hazards (R) in 341 (Accessibility Content) $7 Data provenance (R) in 341 (Accessibility Content) Codes a - Activity report in Continuing Resources 008/21 (Type of continuing resource) (006/04) i - Serial zine in Continuing Resources 008/21 (Type of continuing resource) (006/04) q - Serial podcast in Continuing Resources 008/21 (Type of continuing resource) (006/04) ■ Changes in content designator names and definitions: Fields 041Language Code field definition and scope redescribed 341Accessibility Content field definition and scope redescribed Indicator values 0Adaptive features to access primary content renamed Accessibility information related to primary content and redescribed in 341 (Accessibility Content) 1st indicator: Application 1Adaptive features to access secondary content renamed Accessibility information related to secondary content and redescribed in 341 (Accessibility Content) 1st indicator: Application Character Position 008/35-37 - Language redescribed in 008 (All Materials) Code # - None of the following redescribed in Continuing Resources 008/21 (Type of continuing resource) (006/04) ||| - No attempt to code redescribed in All Materials 008/35-37 (Language) ■ Fast-track changes: Subfield $a Language code of text/sound track or separate title renamed Language code of text or sound track in 041 (Language Code) Code sgn - Sign languages redescribed in All Materials 008/35-37 (Language) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 8658] Don't display patron attributes which have been limited to another patron category
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8658 Sara Brown <sbrown(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sbrown(a)bywatersolutions.com --- Comment #3 from Sara Brown <sbrown(a)bywatersolutions.com> --- This is still an issue in 26.05.04. Even if a patron never belonged to a category to which an attribute applied (so, the field is blank for that patron), the attribute still shows in their OPAC account. This may become a problem for more libraries now that patrons can renew their accounts online via the OPAC, since doing so requires that patrons verify their account details. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 41702] New: Update MARC21 authority frameworks to Update 41 (December 2025)
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41702 Bug ID: 41702 Summary: Update MARC21 authority frameworks to Update 41 (December 2025) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org https://www.loc.gov/marc/authority/adapndxf.html UPDATE 41 CHANGES ■ New content designators: Subfields $i Relationship information (R) in 368 (Other Attributes of Person or Corporate Body) $i Relationship information (R) in 376 (Family Information) $i Relationship information (R) in 381 (Other Distinguishing Characteristics of Work or Expression) $4 Relationship (R) in 368 (Other Attributes of Person or Corporate Body) $4 Relationship (R) in 376 (Family Information) $4 Relationship (R) in 381 (Other Distinguishing Characteristics of Work or Expression) ■ Changes in content designator names and definitions: Subfield $2 Source redescribed in 368 (Other Attributes of Person or Corporate Body) Appendix HData Provenance Subfields: Data Provenance Code List moved to https://www.loc.gov/standards/valuelist/dataprov.html. New codes bcp47 and dpets added. ■ Fast-track changes: Subfields $g Conversion date renamed Conversion date/time and redescribed in 884 (Description Conversion Information) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 43797] New: Adding Item Number to holdings table
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43797 Bug ID: 43797 Summary: Adding Item Number to holdings table Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: sam.young(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 42001] New: Add duplicate purchase order number detection on EDI quote import
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42001 Bug ID: 42001 Summary: Add duplicate purchase order number detection on EDI quote import Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: hdunne-howrie(a)westminster.gov.uk, kyle(a)bywatersolutions.com, testopia(a)bugs.koha-community.org Depends on: 40383, 41297 Blocks: 38195 EDIFACT quote processing will detect duplicate purchase order numbers and block basket creation from those orders when using the po_is_basketname setting for EDIfact processing. We should add the ability to notify the supplier, and alert library staff. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38195 [Bug 38195] EDI/Edifact classes should use Koha::Objects instead of plain DBIC https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40383 [Bug 40383] Modernise the EDIFACT Message display modal https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41297 [Bug 41297] Add duplicate invoice number detection on EDI invoice import -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59

[Bug 39215] New: EDIFACT quote files should skip orders that cannot be processed rather than failing to complete
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39215 Bug ID: 39215 Summary: EDIFACT quote files should skip orders that cannot be processed rather than failing to complete Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org When loading an EDIFACT quote file, if the process finds problematic data (usually a mismatched LLO - Branchcode or other enumerated coded field) the load process gets stuck and displays as 'Processing' in the EDFACT messages page. This usually means that the remainder of the quotes in the file have to be manually corrected and is it's currently difficult to debug by library staff. It would be preferable if the process could skip, and report any problem data but complete all other quotes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30