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

[Bug 41091] New: Add ISO18626 to ILL for borrowing
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41091 Bug ID: 41091 Summary: Add ISO18626 to ILL for borrowing Initiative type: --- Sponsorship --- status: 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: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Bug 37762 is adding lending to Koha using the ISO18628 spec. It would be a good followup if we could also using ISO for borrowing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 43673] New: Memcached problem causes incorrect syspref values
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43673 Bug ID: 43673 Summary: Memcached problem causes incorrect syspref values Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Occasionally, I have this issue where processes (like starman) act strangely - as if a system preference is 0 instead of 1. You look at the database and everything is fine. So you restart memcached and everything magically works again. This suggests to me that perhaps memcached is returning the wrong values, Koha has a bug in Koha::Cache, or Koha isn't handling errors in memcached, or a different Koha is overriding the value for another instance's memcached, or... something I can't even think of yet. I haven't been able to reproduce it: - If I exceed the memcached connection limit, it fails to fetch and it just goes straight to the DB, which is correct. - I've tried exceeding the memory limit but that's tricky to measure, so I don't know if I've exceeded that limit necessarily I'm not sure... but wanted to record something here... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 39962] New: Recalled status does not show properly on staff interface record detail page
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 Bug ID: 39962 Summary: Recalled status does not show properly on staff interface record detail page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To reproduce: 1. Enable the UseRecalls system preference and set the recalls-related circulation and fines rules. 2. Search for an item. 3. Check out an item to Patron B. 4. Log into the OPAC as Patron A. 5. Request a record-level recall on the record. 6. View the record on the staff interface and look at the holdings table. Notice that the checked out item shows no indication of being recalled, but the recall request does show on the Recalls tab. --> BUG 7. Go to the Recalls tab and cancel the recall. 8. Go back to the OPAC and request an item-level recall on the checked out item. 9. View the record on the staff interface and look at the holdings table. Notice that the checked out item now shows the recalled status, twice. "Recalled by koha (42) on DATE" --> BUG -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 19642] New: If autoMemberNum is enabled, we should just ignore cardnumber entry in BorrowerMandatoryField
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19642 Bug ID: 19642 Summary: If autoMemberNum is enabled, we should just ignore cardnumber entry in BorrowerMandatoryField Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com Bug 19225 proposes a warning for users that the config is wrong. I propose instead, we should just ignore that field if automembernum is enabled (since it autocalculates and becomes mandatory -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 43666] New: Allow plugins to register additional Single Table Inheritance subclasses
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43666 Bug ID: 43666 Summary: Allow plugins to register additional Single Table Inheritance subclasses Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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 Target Milestone: --- This patch adds Koha::Objects::Mixin::SingleTableInheritance::Pluggable, an extension of the Koha::Objects::Mixin::SingleTableInheritance mixin added in bug 43663. It lets an installed and enabled Koha Plugin register additional Single Table Inheritance (STI) subclasses against a Koha::Objects plural class, provided all of the following are true: 1. The plural class itself opts in at the code level, by composing this mixin instead of the base one. This is a core developer decision, not overridable at runtime. 2. The contributing plugin has been explicitly permitted, for that specific target plural class, via a new per-plugin, per-target toggle in the Plugin management UI. Off by default for every (plugin, target) pair. 3. A new koha-conf.xml entry, enable_plugin_sti_registration, is enabled. Off by default; a full kill-switch overriding both of the above when off, for hosts who want to forbid the capability outright. Discovery reuses Koha's existing Koha::Plugins::GetPlugins({ method => ... }) capability-declaration mechanism (the same approach Koha::SuggestionEngine and Koha::RecordProcessor already use for their own plugin discovery) - no new registry, no filesystem scanning, no Module::Pluggable. A permitted plugin declares its contributions via one public method, additional_sti_classes, returning a hash keyed by target plural class name; each named class self-declares its own dispatch key exactly like a core STI subclass does (see bug 43663), so that key is never duplicated between the plugin and core. A core-registered dispatch key always wins over any plugin contribution. An invalid contribution (fails to load, isn't a subclass of the target's own base class, or doesn't implement the dispatch-key method) is dropped with a logged warning, never a fatal error, so one misbehaving plugin cannot break dispatch for any other row or any other plugin. Koha::File::Transports (already migrated onto the base mixin in bug 43663) is opted into this new capability as the proving-ground consumer, with no other behaviour change - confirmed by the full existing File::Transport test suite passing unmodified with the new capability left at its default (off). This is designed to let a plugin trial a new subclass (for example, an additional file transport backend) without requiring a core patch first; if it proves itself, promoting it into core is a small, two-line change (move the file, add it to the plural class's own reviewed subclass list) with no data migration, since dispatch is driven purely by the persisted column value, not by which mechanism supplied the class. Depends on bug 43663 (Koha::Objects::Mixin::SingleTableInheritance), which this bug builds directly on top of. Test plan: 1. Apply the patches and restart_all. 2. Confirm Administration > File transports behaves identically to before this patch, with everything left at its defaults (no visible change is the expected result at this step). 3. Set enable_plugin_sti_registration to 1 in koha-conf.xml, restart_all. 4. Install and enable a plugin implementing additional_sti_classes for Koha::File::Transports (a companion example plugin will be linked from this bug's comments). 5. In the Plugin management UI's actions menu for that plugin, confirm an option to allow registering classes for Koha::File::Transports appears, and toggle it on. 6. Go to Administration > File transports, create a new file transport using the plugin-contributed transport type, and confirm it dispatches to the plugin's class. 7. Toggle the permission back off. Confirm the plugin-contributed transport type is no longer offered, and any already-created row of that type falls back to generic behaviour rather than erroring. 8. Set enable_plugin_sti_registration back to 0. Confirm re-toggling permission on in the Plugin management UI has no effect while the kill-switch is off. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 43333] New: Restore the name of the vendor as h1 in vendor details page
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43333 Bug ID: 43333 Summary: Restore the name of the vendor as h1 in vendor details page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- While testing 26.05 prior to rolling it out to our clients, the team noticed that in the vendor's details page, the name of the vendor is not prominent anymore. There is a h2 that says "Vendor #x" but the name of the vendor is only in the small section in the details. For most end users, they don't care that this is vendor #1, #2 or #38. They tell the vendors apart by their name. I can't tell which bug changed this because for some reason vue pages don't react well to git checkout (or maybe I just don't know how it works which is also a possibility). In 25.05.05 which is the version our clients currently use, the vendor name is in an h1. In main (and 26.05.02), the vendor # is in an h2 and, as far as I can tell, there is no h1. To recreate : 1. In KTD, go to Acquisitions 2. Click Search in the vendor search box 3. Click "My vendor" --> The biggest title on the page is "Vendor #1" --> "My vendor" is in the breadcrumbs and in the form, but both are small and a bit lost in the rest of the information 4. Inspect the title "Vendor #1" --> It's a h2 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 42814] New: Advance notice checkboxes enabled in inactive messaging preferences form
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42814 Bug ID: 42814 Summary: Advance notice checkboxes enabled in inactive messaging preferences form Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Bug 28308 added JavaScript to disable the Advance notice transport checkboxes when "Days in advance" is blank. However, the JavaScript only checks the value of the days select. When the messaging preferences form is inactive/read-only and a non-blank days value is selected, the script removes the disabled state from the checkboxes. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 43672] New: When a patron has no advance notices value and their category is changed to one with a value the checkboxes are not enabled
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43672 Bug ID: 43672 Summary: When a patron has no advance notices value and their category is changed to one with a value the checkboxes are not enabled Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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, kyle(a)bywatersolutions.com Target Milestone: --- To recreate: 1 - Have two patron categories one with messaging preference default with advance notices days and email set one with no messaging preference defaults 2 - Save a patron in the category with no defaults 3 - Edit the patron, change their category to the one with a default 4 - Note the checkbox for email is disabled, but days dropdown is set 5 - Save 6 - Note the patron has days set, but no transport -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 42605] New: Acquisition Items not listed during receipt
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42605 Bug ID: 42605 Summary: Acquisition Items not listed during receipt Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Ensure AcqCreateItem is set to 'placing an order' at syspref or on basket 2 - Open a basket, add an order, and add several items 3 - Close the basket and receive shipments 4 - Select the order and 'Receive selected' or click 'Receive' on the order 5 - No items are listed in the items section -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 41688] New: Refund modal and amount as NaN, rejected comma separator
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41688 Bug ID: 41688 Summary: Refund modal and amount as NaN, rejected comma separator Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Hello @ll The problem here is on the refund modal, when retrieving the default value before being modified it is NaN because in some cases for decimal separators with comma, the recovery fails due to formatting a value already formatted in js. After a quick search I think it's a return of bug 31513 fix -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25