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

[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 42291] New: Tidy all script tags - shelves
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '26

09 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42291 Bug ID: 42291 Summary: Tidy all script tags - shelves Initiative type: --- Sponsorship --- status: 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: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 42094 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42094 [Bug 42094] Tidy all script tags (except value_builder) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[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

[Bug 36694] New: Remove HC Sticky library in favor of CSS
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '26

09 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36694 Bug ID: 36694 Summary: Remove HC Sticky library in favor of CSS Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CSS sticky is now widely available across major browsers. I think we can use it instead of the HC sticky library now. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 167

[Bug 42778] New: Editing SIP configuration through staff interface can silently change default behavior on upgraded systems
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '26

09 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42778 Bug ID: 42778 Summary: Editing SIP configuration through staff interface can silently change default behavior on upgraded systems Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Depends on: 37839 I noticed and confirmed this bug for the setting "Holds get captured", but I'm not sure if it affects other settings as well. Before bug 37893, if a SIP account did not have a value defined in koha-conf for holds_get_captured, the default behavior was to capture holds. However, the staff interface editor for SIP accounts only has the options "Yes" and "No", and when the page loads, it selects the "No" radio button if the value is undefined. As a result, if a staff administrator edits any other field of the SIP account and saves changes, that undefined value (which previously did capture holds) gets silently set to "no", don't capture holds. I can confirm that the following settings do *not* have this bug, as the default behavior is "No" if the setting is undefined: allow additional materials checkout allow empty passwords format due date holds block checkin block previous checkout I'm not sure about the following settings - they should be tested: checked in ok CT always send CV always send 00 on success CV triggers alert disallow overpayment error detect overdues block checkout send patron home library in AF show checkin message show outstanding amount It would probably be safest to explicitly set the default values for these yes/no fields on upgrade (including the ones whose default is already "no" for future-proofing), as well as add a database update to main to set any undefined values to the correct defaults. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37839 [Bug 37839] /api endpoint stops working on strict firewall -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4