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

[Bug 42571] New: Sending EDI order results in variable no available warnings
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42571 Bug ID: 42571 Summary: Sending EDI order results in variable no available warnings Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The warnings look like: [2026/05/08 15:02:42] [32918] [WARN] Variable "@messages" is not available at /usr/share/koha/intranet/cgi-bin/acqui/basket.pl line 698. [2026/05/08 15:02:42] [32918] [WARN] Variable "$op" is not available at /usr/share/koha/intranet/cgi-bin/acqui/basket.pl line 704. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 42551] New: C3 merge error when syntax checking installed plugins
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42551 Bug ID: 42551 Summary: C3 merge error when syntax checking installed plugins Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Running "perl -cw" on a plugin to check for syntax errors can result in: Inconsistent hierarchy during C3 merge of class 'Koha::Plugin::Com::ByWaterSolutions::MessageBee': current merge results [ Koha::Plugin::Com::ByWaterSolutions::MessageBee, ] merging failed on 'Koha::Plugins::Base' at /usr/share/perl/5.28/base.pm line 186. This is because the plugin was already loaded, then loaded again resulting in this weird error. To be clear, this doesn't happen in production. Only when I syntax check a plugin. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 42912] New: Javascript error on opac-readingrecord when no Circulation history
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42912 Bug ID: 42912 Summary: Javascript error on opac-readingrecord when no Circulation history Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes.

1 14

[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 18 Sep '26

18 Sep '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 19

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

18 Sep '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 39

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

18 Sep '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 28

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

18 Sep '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 28

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

18 Sep '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 17

[Bug 42159] New: With OPACAuthorIdentifiersAndInformation information lacking from field 110/111
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42159 Bug ID: 42159 Summary: With OPACAuthorIdentifiersAndInformation information lacking from field 110/111 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org When the OPACAuthorIdentifiersAndInformation system preference is enabled, selected information about authors is displayed. However, if the main author is a corporate body or a meeting/conference (MARC 21 fields 110/111), the information is not shown. To reproduce: 1. Enable the display of identifiers in OPACAuthorIdentifiersAndInformation. 2. Add a 024 field with a VIAF ID to any corporate authority record, e.g.: 024 7# $a 1234 $2 viaf 3. Use this authority heading as the main entry (110 or 111) in any bibliographic record. 4. In the OPAC view of that bibliographic record, verify that the Author information tab does not display information from the main entry. 5. Use the same heading as an added entry (710 or 711). In the OPAC view, verify that the Author information tab now displays information from the added entry, but still not from the main entry. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 42825] New: ERM Local Title - Start date (started_on) not saved for package resources
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42825 Bug ID: 42825 Summary: ERM Local Title - Start date (started_on) not saved for package resources Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk Target Milestone: --- When editing a local ERM Title and linking it to a package, the Start date (started_on) field is not saved — it remains empty after saving and reopening the record. The End date (ended_on) and Proxy fields save correctly. Steps to reproduce: 1 Go to ERM > eHoldings > Local > Titles 2 Create or edit a local title 3 Link it to at least one package and enter a Start date (and optionally an End date and Proxy) 4 Save 5 Reopen the title — Start date is empty; End date and Proxy are saved correctly The root cause of the error: In koha-tmpl/intranet-tmpl/prog/js/vue/components/ERM/EHoldingsLocalTitleResource.vue, the started_on field inside relationshipFields is missing indexRequired: true. This property causes the form system to generate a unique DOM id per row (e.g. started_on_0) and passes the row index to the component. Without it, the id stays as started_on, breaking the reactive binding between the flatpickr input and the Vue data model. The ended_on field does not have componentProps, so it is not affected. The started_on field does have componentProps.date_to which alters how the component id is expected to be resolved, making it the only field that fails without indexRequired. Additionally, calendar.inc throws a TypeError: Cannot read properties of null (reading '_flatpickr') in the browser console when selecting a start date, because the date_to componentProp references ended_on without the row index suffix. See also: Bug 42536 — while investigating why the Proxy field was not displayed in the resource view, the missing Start date in the edit form was identified as a related but separate issue in the same component (EHoldingsLocalTitleResource.vue). -- You are receiving this mail because: You are watching all bug changes.

1 13