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

[Bug 42943] New: Spine labels not formatting correctly
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 Bug ID: 42943 Summary: Spine labels not formatting correctly Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: PC OS: Windows Status: NEW Severity: major Priority: P5 - low Component: Label/patron card printing Assignee: chris.nighswonger(a)veritassuperaitsolutions.com Reporter: sarah.harvey1(a)health.nsw.gov.au QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Created attachment 201228 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201228&action=e… Example of pdf generated to print labels. Call number running long instead of splitting. Since the recent update to Version 25.11, our spine labels are not splitting the call number, see attached file. I have fiddled with settings but cannot get the issue to resolve. Settings are back as to before, I can only attach one file here, will see if I can attach another with the settings once submitted. I note a previous bug where the issue was that the call numbers where nlm, where if lcc was selected, the call number would split. We use DDC. -- You are receiving this mail because: You are watching all bug changes.

1 31

[Bug 42430] New: Fix issue with stale plugin methods after plugin upgrade
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42430 Bug ID: 42430 Summary: Fix issue with stale plugin methods after plugin upgrade Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When a plugin is upgraded in place (that is, uploading a new version over the old one), the list of methods Koha knows about for that plugin can get out of date. For example, if a plugin used to have a "tool" method and the new version renames it to "admin", the staff interface can still show the old "Run tool" link, and clicking it produces an error saying the plugin has no "tool" method. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 42664] New: Changes to SIP2 accounts may not applied immediately
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Bug ID: 42664 Summary: Changes to SIP2 accounts may not applied immediately Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org SIP2 accounts/institutions are stored in the database and the SIP server is supposed to reload its configuration when they change. In practice, after adding or editing a SIP2 account, most SIP worker processes keep serving the old configuration (e.g. new accounts get "SIP access not authorized") until the SIP server is restarted ( I tested multiple times over 30 minutes ). There seem to be two issues: * L1 cache flushed too late. process_request() calls _config_up_to_date() before Koha::Caches->flush_L1_caches(). The SIP parent reads sip2_resource_last_modified into its own L1 cache at startup and never flushes it. Every worker inherits that stale L1, so a worker's first connection compares against the startup-era value instead of the current shared value. * sip2_config_read_timestamp is stored in the shared (memcached) cache, but the configuration it tracks is per-process. When one worker reloads the config from the database, it bumps the shared timestamp, so every other worker then evaluates as "up to date" and never reloads its own stale in-memory config. Also, Koha::SIP2::Object::store bumps the timestamp before SUPER::store, opening a race condition where a worker reloading during db update transaction caches a config that is missing the new row. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 42654] New: Bug 33907 regression: section missing from OPAC course reserve detail page
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42654 Bug ID: 42654 Summary: Bug 33907 regression: section missing from OPAC course reserve detail page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Bug 33907 ("Improve translation of title tags: OPAC part 1") introduced a regression against Bug 35978 ("Add 'sections' to Course Reserves"). When Bug 33907 replaced the hard-coded strings in opac-course-details.tt with tx() calls, it dropped the conditional section suffix from three places: - <title> tag - Active breadcrumb item - <h1> heading This patch restores the section display using the correct i18n approach: two separate tx() keys, one with section and one without, selected via [%- IF course.section -%]. Test plan: 1. Enable UseCourseReserves. 2. Create a course with a Section value (e.g. "Residential"). 3. Navigate to the OPAC course reserves detail page for that course. 4. Confirm the page <title>, breadcrumb, and <h1> all include the section. 5. Create a course without a Section value. 6. Confirm the page <title>, breadcrumb, and <h1> show only the course name. -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 42645] New: ModSuggestion: FallbackToSMSIfNoEmail ignores EmailFieldPrimary/EmailFieldPrecedence
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42645 Bug ID: 42645 Summary: ModSuggestion: FallbackToSMSIfNoEmail ignores EmailFieldPrimary/EmailFieldPrecedence 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org The transport-selection logic in C4/Suggestions.pm (ModSuggestion, ~line 253) checks !$patron->email when deciding whether to fall back to SMS for purchase-suggestion status-change notices (ACCEPTED, AVAILABLE, REJECTED, ORDERED, CHECKED). $patron->email returns the raw borrowers.email column value and does not consult the EmailFieldPrimary or EmailFieldPrecedence system preferences. The correct method is $patron->notice_email_address, which applies those preferences. A patron who has only emailpro or B_email populated (with borrowers.email empty) will incorrectly receive their status-change notice via SMS even when they have a valid, reachable email address, because the FallbackToSMSIfNoEmail check sees an empty borrowers.email and treats the patron as having no email at all. See also: Bug 39984 Test plan: 1. Enable FallbackToSMSIfNoEmail. 2. Set EmailFieldPrimary to emailpro (or EmailFieldPrecedence to emailpro|email|B_email). 3. Create a patron with emailpro populated, borrowers.email empty, and smsalertnumber set. 4. Submit a purchase suggestion as that patron and accept it. 5. Check the message_queue table. 6. Without patch: the ACCEPTED notice is queued with message_transport_type = 'sms'. 7. Apply patch: the ACCEPTED notice is queued with message_transport_type = 'email' and sent to the emailpro address. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 42453] New: "About Koha" breaks if Elasticsearch is used but unavailable
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42453 Bug ID: 42453 Summary: "About Koha" breaks if Elasticsearch is used but unavailable Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org To reproduce in KTD: - Start KTD with ES: $ ktd --search-engine es8 up - Look at the "About Koha" page and verify it says ES is running - Stop the ES container: $ docker stop kohadev-es-1 - Reload "About Koha" and verify there is an error On KTD I get a stacktrace-type error page. On a live 25.05 install I get an error 500 page. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 42535] New: Remove useless "news_delete" javascript in staff interface
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42535 Bug ID: 42535 Summary: Remove useless "news_delete" javascript in staff interface Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In koha-tmpl/intranet-tmpl/prog/en/modules/intranet-main.tt there is a block of Javascript which doesn't do anything as there appears to be no news delete element on the staff interface main page: [% MACRO jsinclude BLOCK %] <script nonce="[% Koha.CSPNonce | $raw %]"> var MSG_CONFIRM_DELETE = _("Are you sure you want to delete this news item? This cannot be undone."); $(document).ready(function () { $(".news_delete").on("click", function () { return confirmDelete(MSG_CONFIRM_DELETE); }); }); </script> [% END %] As far as I can tell, this can be deleted. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 42909] New: Suspend class missing from suspended holds on request.pl
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42909 Bug ID: 42909 Summary: Suspend class missing from suspended holds on request.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Depends on: 23269 Target Milestone: --- When viewing the holds list for a particular biblio record, the tr (table row) elements previously had a "suspend" class, allowing CSS styling of suspended holds. As of 25.11.05, that class is missing. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23269 [Bug 23269] Long hold queues are slowing the service -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 42321] New: Breeding should handle empty results from SRU targets better
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42321 Bug ID: 42321 Summary: Breeding should handle empty results from SRU targets better Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently we see lots of warnings on e.g. the Folio LOC SRU server like: LOC SRU record 3: 61 LOC SRU record 4: 0 LOC SRU record 5: 0 LOC SRU record 6: 0 LOC SRU record 7: 0 LOC SRU record 8: 0 LOC SRU record 9: 0 LOC SRU record 10: 0 LOC SRU record 11: 0 LOC SRU record 12: 0 LOC SRU record 13: 0 LOC SRU record 14: 0 LOC SRU record 15: 0 LOC SRU record 16: 0 LOC SRU record 17: 0 LOC SRU record 18: 0 LOC SRU record 19: 0 LOC SRU record 20: 0 These are just empty results. (Note in a larger perspective, we probably should not search those SRU targets via the (old) ZOOM object.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 41889] New: Checkouts api call for checked in items can fail if the patron has been deleted
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41889 Bug ID: 41889 Summary: Checkouts api call for checked in items can fail if the patron has been deleted Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com To recreate: Checkout an item to a patron without anonymization and check it back in. Do a call to your instance (may need to turn on api basic auth and just use your credentials) that includes the date in question, see that you get a result. Delete the patron and send the call again, you'll get the error message at the bottom of the comment. This is a problem with third party report services. {ktdurl}/api/v1/checkouts?q={"checkout_date":{">": "2026-01-24T00:00:00Z","<": "2026-07-31T00:00:00Z"}}&checked_in=true&_per_page=5000&_page=1&_order_by=checkout_date Recreated on main, seeing it back at least to old stable. { "errors": [ { "message": "Expected integer - got null.", "path": "/body/0/patron_id" }, -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16