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

[Bug 39031] New: ILL plugins should provide themselves the template path
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39031 Bug ID: 39031 Summary: ILL plugins should provide themselves the template path Change sponsored?: --- Product: Koha Version: Main 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: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com Right now, Koha assumes (in `Koha::ILL::Request->expand_template`) that `$plugin->new_ill_backend` returns a Koha::Plugin object that implements the required methods for acting like a proper ILL backend. This is implied by the internal use of `bundle_path`: ```perl my $backend_plugin = $self->get_backend_plugin( $self->_backend->name ); if ($backend_plugin) { # New way of loading backends: Through plugins $backend_dir = $backend_plugin->bundle_path; $backend_tmpl = $backend_dir; ``` I'm writing a backend plugin that has a convenient `templates/` dir to better organize the many pieces. My `new_ill_backend()` method returns a new object that is designed to eventually inherit from `Koha::ILL::Backend` when time comes. The current implementation assumes that everything is contained in the plugin's bundle path in a very specific way. I propose we either allow the backend to tell where to look for templates: ```diff - $backend_dir = $backend_plugin->bundle_path; + $backend_dir = $self->_backend->template_path; ``` or implement a plugin method for the job: ```diff - $backend_dir = $backend_plugin->bundle_path; + $backend_dir = $backend_plugin->ill_template_path; ``` i.e. just implement a plugin method, that will return the path for querying the backend templates I'd go with the first option, leaving it to the author's creativity to organize things the way they want. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 40529] New: Update how hold groups work
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40529 Bug ID: 40529 Summary: Update how hold groups work Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 88

[Bug 34556] New: Add a template 'Accessibility statement' page to the default data
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34556 Bug ID: 34556 Summary: Add a template 'Accessibility statement' page to the default data Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 23003 We should add a template 'accessibility statement' using the pages feature of Koha and add it optionally to the installer default data. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23003 [Bug 23003] Accessibility improvements -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #233 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- (In reply to Victor Grousset/tuxayo from comment #232) > I got around 28 tests failing. On a ktd started with the patches. And also > when starting on main and upgrading. And with defaultCommandTimeout: 20000 > (that's what is usually needed on my slow laptop) > > Is there something else to do to run the tests besides starting KTD and > running them directly? > cypress run --config video=false --spec > t/cypress/integration/Admin/CirculationTriggers_spec.ts > > Otherwise that looks like a legit failure. For example, for "Should display > correct breadcrumbs", the .current class is indeed not on "Home". > > > --- > > For the next patch version, can the steps to perform an upgrade added to the > test plan? > > From what I have gathered it's: > > sudo perl /kohadevbox/misc4dev/cp_debian_files.pl --instance=kohadev > --koha_dir=/kohadevbox/koha --gitify_dir=/kohadevbox/gitify > yarn build > > But maybe they are wrong. And it took me some time to find about needing > cp_debian_files.pl > > ---------- > > If I want to test the migration of the old triggers. Is there any > interesting data to test? Or do I just put multiple triggers and check that > the most popular stuff is picked as default? > > ------- > > 1. open the form "Confirm trigger context" > 2. click on the "Patron category" list > 3. try to scroll because you aren't finding the desired category > 4. It barely scrolls. > > You have to thing about moving the mouse outside of the list and scroll > there. > If the size of the things lines up enough, when trying to scroll you don't > get to see the beginning of the next patron category. So you can really > think the list is 3 or 4 elements long and that's all. I almost reported > that the list was incomplete instead of reporting this. > > ------ > > When not logged into Koha and going to > http://localhost:8081/cgi-bin/koha/admin/circulation_triggers > One is redirected to the login page. > After login, the redirection is done to > http://localhost:8081/cgi-bin/koha/admin/circulation_triggers.pl > Which isn't valid and goes 404. > I though I missed some setup step at some point. But it was just an invalid > redirect. > Maybe it's from the rewrite rule in > debian/templates/apache-shared-intranet.conf Hi Victor, Many thanks for the feedback! I have a few UI/UX and permission fixes in the work (which includes dropdown select / scroll behaviour improvements, and should address what you've reported here), working from testing feedback from Michaela, and I'm aiming to resubmit by Friday this week. I'll be taking a look at the failing cypress tests as well. For data migration testing, what you've described is in effect what I have done. I haven't stumbled upon any particular edge case that needs looking into. The login/redirect fail: I'll need to look into that one. What I can say is the URL needs to be http://localhost:8081/cgi-bin/koha/admin/circulation_triggers, not http://localhost:8081/cgi-bin/koha/admin/circulation_triggers.pl. I'll see if the RewriteRules can help resolve this. I did find the new circulation triggers RewriteRule was missing from etc/koha-httpd.conf (fix not submitted yet - another one for Friday!) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 Victor Grousset/tuxayo <victor(a)tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #232 from Victor Grousset/tuxayo <victor(a)tuxayo.net> --- I got around 28 tests failing. On a ktd started with the patches. And also when starting on main and upgrading. And with defaultCommandTimeout: 20000 (that's what is usually needed on my slow laptop) Is there something else to do to run the tests besides starting KTD and running them directly? cypress run --config video=false --spec t/cypress/integration/Admin/CirculationTriggers_spec.ts Otherwise that looks like a legit failure. For example, for "Should display correct breadcrumbs", the .current class is indeed not on "Home". --- For the next patch version, can the steps to perform an upgrade added to the test plan? >From what I have gathered it's: sudo perl /kohadevbox/misc4dev/cp_debian_files.pl --instance=kohadev --koha_dir=/kohadevbox/koha --gitify_dir=/kohadevbox/gitify yarn build But maybe they are wrong. And it took me some time to find about needing cp_debian_files.pl ---------- If I want to test the migration of the old triggers. Is there any interesting data to test? Or do I just put multiple triggers and check that the most popular stuff is picked as default? ------- 1. open the form "Confirm trigger context" 2. click on the "Patron category" list 3. try to scroll because you aren't finding the desired category 4. It barely scrolls. You have to thing about moving the mouse outside of the list and scroll there. If the size of the things lines up enough, when trying to scroll you don't get to see the beginning of the next patron category. So you can really think the list is 3 or 4 elements long and that's all. I almost reported that the list was incomplete instead of reporting this. ------ When not logged into Koha and going to http://localhost:8081/cgi-bin/koha/admin/circulation_triggers One is redirected to the login page. After login, the redirection is done to http://localhost:8081/cgi-bin/koha/admin/circulation_triggers.pl Which isn't valid and goes 404. I though I missed some setup step at some point. But it was just an invalid redirect. Maybe it's from the rewrite rule in debian/templates/apache-shared-intranet.conf -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41725] New: Limit holds on itemtype/biblio for set number of days
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41725 Bug ID: 41725 Summary: Limit holds on itemtype/biblio for set number of days Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Would like to see a hold limiter via itemtype and biblio to limit holds. Something like: Limit patrons to X number of holds within X number of days -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 41724] New: Limit hold requests per set number of days
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41724 Bug ID: 41724 Summary: Limit hold requests per set number of days Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Would like to see hold limits globally and per patron category. Something like: Patron may place X number of holds per X days. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 41722] New: Argument "" isn't numeric in numeric gt (>)... warnings in opac-detail.tt
by bugzilla-daemon＠bugs.koha-community.org 27 Jan '26

27 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41722 Bug ID: 41722 Summary: Argument "" isn't numeric in numeric gt (>)... warnings in opac-detail.tt Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: roman.dolny(a)jezuici.pl QA Contact: testopia(a)bugs.koha-community.org The warning: [WARN] Argument "" isn't numeric in numeric gt (>) at /kohadevbox/koha/koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-detail.tt line 1578. appears in the plack-opac-error.log. It is quite strange because warning only appears when opac-detail.pl is used for very first time to show record. To reproduce: 1a. Use a fresh KTD or 1b. edit opac-detail.tt (save an insignificant change, like add a space) and restart plack. 2. Observe plack-opac-error.log. 3. Go to any bibliographic record with items in OPAC., e.g. search for "Perl template toolkit". ==> Warnings should appear in plack-opac-error.log ==> (as many as there are items). 4. Restart plack 5. Back to OPAC and refresh view of bibliographic record. ==> No warnings appear. 5. Repeat 1b., 4. and 5. ==> Warnings appear. It seems that check of existens "item_level_holds" is needed before using it in IF condition, but I can't find why warning appers in log only once, not every time when "item_level_holds" is checked in IF. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41210] New: Author field searches do not include enough fields
by bugzilla-daemon＠bugs.koha-community.org 27 Jan '26

27 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41210 Bug ID: 41210 Summary: Author field searches do not include enough fields 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com For author fields like 110 / 710 we may have subordinate units or other info which is relevant to finding related records, currently none of these subfields are search so something like: Paris. Salon (Société des artistes français) Searches just: Paris. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 40762] New: MARC records containing empty tags return a 500 error
by bugzilla-daemon＠bugs.koha-community.org 27 Jan '26

27 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40762 Bug ID: 40762 Summary: MARC records containing empty tags return a 500 error Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: lynn.uhlman(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Imported records containing invalid empty tags are getting a 500 error when trying to view the record. Additionally, they prevent indexing from occurring since the index fails on records with empty tags. In addition, reindexing fails on these records. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2