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

[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

[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

[Bug 42663] New: Koha::Context must be object-oriented designed
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '26

09 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42663 Bug ID: 42663 Summary: Koha::Context must be object-oriented designed 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: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Discussion from bug 41892 suggested that the new module Koha::Context should have an Object-oriented interface. -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 42798] New: Public lists which allow changes to contents from anyone seeing this list do not allow anyone to change contents
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '26

09 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42798 Bug ID: 42798 Summary: Public lists which allow changes to contents from anyone seeing this list do not allow anyone to change contents Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Public lists allowing 'Anyone seeing this list' should allow at least a logged in anyone to add items to that list. to create: - create a public list for user koha via More -> Lists -> New List - set 'Public' to 'Public' and 'Allow changes to contents from' to 'Anyone seeing this list' - add some titles to this list f.e. search catalog for 'perl' -> select some -> Add to list -> the public list - login via another user to the opac - search for a title not on that public list - try adding it to the public list via 'Save to lists' or 'Add to list' - Sorry, you cannot add items to this list. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 32709] New: Background job UI and REST API routes explode if JSON is incorrect
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '26

09 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32709 Bug ID: 32709 Summary: Background job UI and REST API routes explode if JSON is incorrect Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: Staff interface Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Same as bug 32393, but for the REST API routes and the UI. -- You are receiving this mail because: You are watching all bug changes.

1 7