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

[Bug 35092] New: [OMNIBUS] Remaining background job/worker issues
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '26

09 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35092 Bug ID: 35092 Summary: [OMNIBUS] Remaining background job/worker issues Change sponsored?: --- Product: Koha Version: master 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org 32305 Background worker doesn't check job status when received from rabbitmq 33334 koha-worker.service need update for background job queues 34477 Further reduce memory usage for idle background job worker 34990 34997 Let me add a few more. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 63

[Bug 7923] Performance omnibus
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '26

09 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7923 Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |35092 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35092 [Bug 35092] [OMNIBUS] Remaining background job/worker issues -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42361] SQL Injection in reports/catalogue_out.pl via Filter parameter (error-based, triggered when Criteria matches /branchcode/)
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '26

09 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42361 --- Comment #26 from Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> --- Filed a new report for the regression: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42803 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42361] SQL Injection in reports/catalogue_out.pl via Filter parameter (error-based, triggered when Criteria matches /branchcode/)
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '26

09 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42361 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42803 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42803 [Bug 42803] Regression in reports/catalogue_out.pl -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42361] SQL Injection in reports/catalogue_out.pl via Filter parameter (error-based, triggered when Criteria matches /branchcode/)
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '26

09 Jun '26

1 0

[Bug 28957] Many plugins require the full plugins permission set to run
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '26

09 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28957 Luis Bataller <luis.bataller(a)xercode.es> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |luis.bataller(a)xercode.es --- Comment #11 from Luis Bataller <luis.bataller(a)xercode.es> --- We've actually been carrying a local patch for this at Xercode for over a year now, and it's basically David's comment #8 (option 2): an optional plugin hook that lets the plugin say which permissions a given method needs. The gist of it: - run.pl keeps its current default of { plugins => $method }. - If the plugin implements the hook, run.pl calls it (passing the method and the relevant CGI params) and uses whatever it returns as flagsrequired for get_template_and_user. - The hook returns a normal flagsrequired, or undef to fall back to the default. So nothing changes for plugins that don't implement it. On David's worry in comment #10 (plugins just letting anyone do anything): the hook doesn't return allow/deny. It returns a flagsrequired that Koha still checks itself via haspermission()/get_template_and_user. So a plugin can only pick which existing Koha permission guards a method — it can't bypass the check or drop it below "you need some real Koha permission". Enforcement stays in core. It's also a small, low-coupling change: the only file touched is run.pl, and it's fully backwards-compatible — plugins that don't implement the hook behave exactly as before. A year in production has made us pretty confident in it, and we're glad to tidy it up to community standards. One naming thought: David called it koha_authz in comment #8. We'd actually lean towards permissions_required here, since the hook doesn't grant or do any authorization itself. Happy to go with whatever you all prefer, though. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 27570] New: Allow the ability to alter what a Lost Charge displays for the Patron
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '26

09 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27570 Bug ID: 27570 Summary: Allow the ability to alter what a Lost Charge displays for the Patron 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com A library would like the ability to alter the Lost terminology for their patron's accounting when they are marking something Lost. They had a value of damage to the Lost Status and would like to see Koha bill a patron for a "damaged" book. Currently, Koha will always use the word "Lost" in the Accounting/Fine portion of the patron's record- regardless of what Lost status the library is marking the item as. This could introduce a lot more flexibility when working with libraries and their billing procedures. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 41714] New: MARC21 authorities thesaurus link hardcoded
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '26

09 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41714 Bug ID: 41714 Summary: MARC21 authorities thesaurus link hardcoded 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org UNIMARC heading mapping to thesaurus is read from the MARC bibliographic frameworks. On the other hand, MARC21 has them hardcoded in `C4::Heading::MARC21`. This has the side effect of not letting the linker tools honor the linking configuration from the frameworks. For example, if you define your own thesaurus `CEPAL_TOPIC` which you maintain with your own tools/process, and link it to `650$a`, running the linker will still look for `TOPIC_TERM` yielding bad results. We should have an implementation that: * Allows opting in to a UNIMARC-like behavior * Has a fallback mechanism for not-configured mappings so we wouldn't expect behavior change besides the frameworks-defined mappings * It doesn't reinvent the wheel on an old library -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 35484] New: OPACShelfBrowser secondary sort should be biblio.title not item.itemnumber
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '26

09 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35484 Bug ID: 35484 Summary: OPACShelfBrowser secondary sort should be biblio.title not item.itemnumber Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The OPACShelfBrowser sorts on cn_sort but also includes a secondary sort on itemnumber. This secondary sort is arbitrary and unhelpful, libraries typically don't arrange things on the shelf based on Koha's itemnumber. This secondary sort should be based on title to better refelct how libraries organize shelves. To recreate: 1. In k-t-d, set all item itemcallnumbers to the same thing, ie: 'abcdefg'; 2. Touch all items to update the cn_sort values 3. Turn on OPACShelfBrowser and view a record detail page on the OPAC. 4. Browse the shelf and see that all items are organized by itemnumber. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 35229] New: Add further cypress tests for Usage reporting
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '26

09 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35229 Bug ID: 35229 Summary: Add further cypress tests for Usage reporting Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: matt.blenkinsop(a)ptfs-europe.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com -- You are receiving this mail because: You are watching all bug changes.

1 20