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

[Bug 40422] New: Remove Greybox assets from the staff interface
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40422 Bug ID: 40422 Summary: Remove Greybox assets from the staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 40366, 40412, 40418 Blocks: 8290 Once the last few instances of Greybox usage have been removed we can remove the assets. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8290 [Bug 8290] Replace usage of Greybox modals with Bootstrap modals https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40366 [Bug 40366] Update the label export process to avoid Greybox modal https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40412 [Bug 40412] Update the patron card export process to avoid Greybox modal https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40418 [Bug 40418] Update the item type translation process to avoid Greybox modal -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 39488] New: Update Koha::Object(s) to allow for polymorphic classing
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39488 Bug ID: 39488 Summary: Update Koha::Object(s) to allow for polymorphic classing Change sponsored?: --- Product: Koha Version: unspecified 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org This splits out the proof of concept code in bug 39190 that allows for polymorphic Koha Object classing. We update our Koha::Object(s) classes to pass back $result and propose a signature for class selection with resultsets. This allows for subclassing of an object based on a field in a shared table so one can keep methods grouped for their tasks more easily. Example use cases are (S)FTP where we want to store the basic transport details in one table and then dynamically load the right set of transport protocol specific methods based on the transport type. We might also want to update the Account Line classes to work in a similar way, where we store both debits and credits in one table and would want some shared and some specific methods based on the account line type. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 40850] New: Add `Koha::ILL::Request->add_or_update_attributes`
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40850 Bug ID: 40850 Summary: Add `Koha::ILL::Request->add_or_update_attributes` Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Currently, ILL backends and plugins must implement custom logic to update existing extended attributes on ILL requests, as the core extended_attributes() method only supports adding new attributes and throws duplicate key errors when attempting to update existing ones. This has led to code duplication across multiple ILL plugins (Rapido, INNReach, SLNP) that all implement identical add_or_update_attributes() methods, and forces the Standard backend to use error-prone patterns when managing request metadata. The proposed `add_or_update_attributes()` method in Koha::ILL::Request would provide a safe, efficient way to add new attributes or update existing ones in a single operation, eliminating duplicate key errors and reducing code duplication. This enhancement would immediately benefit the Standard backend (which currently as 6+ locations using the problematic pattern), allow existing plugins to remove their custom implementations, improve performance by only updating attributes when values actually change, and provide a cleaner API for all ILL backend developers. The implementation follows proven patterns already tested in production plugins an d maintains full backward compatibility while solving a common pain point in ILL development. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 40809] New: JS warning should make Cypress tests fail
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40809 Bug ID: 40809 Summary: JS warning should make Cypress tests fail Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 40434] New: Add maxLength to the vendor definition
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40434 Bug ID: 40434 Summary: Add maxLength to the vendor definition 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: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 40175] New: Missing maxLength to REST API specs
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40175 Bug ID: 40175 Summary: Missing maxLength to REST API specs Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com We do not specify the maxLength at the REST API specs level, even if the DB has one defined. Both must match. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 28702] New: Improve performance of C4/XSLT/buildKohaItemsNamespace
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28702 Bug ID: 28702 Summary: Improve performance of C4/XSLT/buildKohaItemsNamespace Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This subroutine prepares items for XSLT parsing in search results, or opac lists. In bug 23414 it was refactored to use Koha::Items to reduce the number of lookups. In reviewing this code, it can be improved further - it is only called by XSLTParse4Display which is only called in 2 places: C4::Search->searchResults opac/opac-shelves.pl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47

[Bug 32702] New: Item statuses that block holds should be checked in CanItemBeReserved
by bugzilla-daemon＠bugs.koha-community.org 26 Dec '25

26 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32702 Bug ID: 32702 Summary: Item statuses that block holds should be checked in CanItemBeReserved Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently true holdability is a combination of CanItemBeReserved/CanBookBeReserved and IsAvailableForItemLevelRequest We should either combine these two routines, or ensure they are both called whenever needed. That is a long term goal, and this bug aims to simply move the item status checks to 'CanItemBeReserved' as they should reduce processing for any unavailable statuses to boost performance, and ultimately improve current functionality. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 55

[Bug 26537] New: Search does not work when no term in value_builder/unimarc_field_4XX.pl
by bugzilla-daemon＠bugs.koha-community.org 26 Dec '25

26 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26537 Bug ID: 26537 Summary: Search does not work when no term in value_builder/unimarc_field_4XX.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Cataloguing plugin value_builder/unimarc_field_4XX.pl has an itemtype filter. It does not work when used without a search term. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 55

[Bug 36518] New: Add unique IDs to the fieldsets of the item search form to facilitate customization
by bugzilla-daemon＠bugs.koha-community.org 26 Dec '25

26 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36518 Bug ID: 36518 Summary: Add unique IDs to the fieldsets of the item search form to facilitate customization Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It would be nice if we could add some IDs to the various section of the item form to make it easier to customize with CSS. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16