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

[Bug 43789] New: EDI quote processing dies with undefined to_json when AcquisitionLog is enabled
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43789 Bug ID: 43789 Summary: EDI quote processing dies with undefined to_json when AcquisitionLog is enabled 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 Target Milestone: --- Koha::EDI::process_quote logs the automatic basket approval with to_json( $approved->unblessed ), but Koha::EDI only imports encode_json from JSON: use JSON qw( encode_json ); so when a vendor has auto_orders enabled and the AcquisitionLog system preference is on, edi_cron.pl fails after the order has been generated and the basket closed: Undefined subroutine &Koha::EDI::to_json called at Koha/EDI.pm line NNN. The APPROVE_BASKET entry is never written to the action log and processing of any remaining auto-ordered baskets in the same run is aborted. Test plan: 1. Enable the EDIFACT and AcquisitionLog system preferences. 2. Configure a vendor EDI account with quotes_enabled and auto_orders enabled. 3. Process a quote for that vendor (misc/cronjobs/edi_cron.pl, or process_quote in a test). 4. Without the patch: Undefined subroutine &Koha::EDI::to_json is raised. 5. Apply the patch and repeat: no error, the basket is closed, the EDI order is created and an ACQUISITIONS / APPROVE_BASKET entry exists in the action logs. 6. prove t/db_dependent/Koha/EDI.t -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 20252] New: If an EDI orderline is cancelled send a cancellation message
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20252 Bug ID: 20252 Summary: If an EDI orderline is cancelled send a cancellation message Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org On cancelling a order if the order has been submitted as an edifact order an ORDCHG message should be generated and transmitted. ORDCHG will contain the order reference and the ean for the item -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 27235] New: Add gzip to package dependencies
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27235 Bug ID: 27235 Summary: Add gzip to package dependencies Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com Both koha-dump and koha-translate (since Bug 24211) use gzip. While it appears to be installed in Debian/Ubuntu by the time we run Koha, we should explicitly reference it as a dependency. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 43696] New: ISO 18626 date-times are not UTC
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43696 Bug ID: 43696 Summary: ISO 18626 date-times are not UTC Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 41789] New: EDIFACT messages broken by unidecode
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41789 Bug ID: 41789 Summary: EDIFACT messages broken by unidecode 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: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org In EDI.pm EDIFACT messages are built and the result is passed to unidecode. However, unidecode replace unicode characters with the transliterated ascii characters which may include characters that have special meaning including apostrophe '. my $order_file = $edifact->encode(); # ingest result if ($order_file) { my $m = unidecode($order_file); # remove diacritics and non-latin chars But this must be done before escaping special characters. For instance: diff --git a/Koha/Edifact/Order.pm b/Koha/Edifact/Order.pm index a36bd7e1b5b..096e66d5f3e 100644 --- a/Koha/Edifact/Order.pm +++ b/Koha/Edifact/Order.pm @@ -27,6 +27,7 @@ use Readonly qw( Readonly ); use Koha::Database; use Koha::DateUtils qw( dt_from_string ); use C4::Budgets qw( GetBudget ); +use Text::Unidecode qw( unidecode ); use Koha::Acquisition::Orders; @@ -685,6 +686,7 @@ sub _interchange_sr_identifier { sub encode_text { my $string = shift; if ($string) { + $string = unidecode( $string ); $string =~ s/[?]/??/g; $string =~ s/'/?'/g; $string =~ s/:/?:/g; -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 43535] New: Support matching EDIFACT invoice lines to orders via RFF+SLI
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43535 Bug ID: 43535 Summary: Support matching EDIFACT invoice lines to orders via RFF+SLI 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 43534 Target Milestone: --- Koha::Edifact::Line already parses the RFF+SLI segment (supplier's unique order line reference number) into orderline_reference_number for both QUOTES and INVOIC messages. However, Koha::EDI's process_invoice only ever matches an incoming invoice line to an aqorders row via RFF+LI (Koha's own internal ordernumber, which the supplier is expected to echo back because Koha sent it in the original EDIFACT ORDERS message). If RFF+LI is missing, or was never set in the first place, the invoice line is skipped and logged as an error - even in cases where RFF+SLI carries a vendor reference that could be matched against aqorders.suppliers_reference_number. Use case: Vendors such as GOBI/YBP support ordering via MARC file import (Koha's MarcFieldsToOrder workflow, see bug 43534) rather than via EDIFACT ORDERS, yet still return EDIFACT INVOIC invoices referencing their own order/line ID via RFF+SLI (e.g. the GOBI order ID). Because Koha never sent an ORDERS message for those lines, there is no RFF+LI value the vendor can echo back, so the invoice lines currently cannot be auto-matched at all. Bug 43534 proposes capturing that vendor reference into aqorders.suppliers_reference_number / suppliers_reference_qualifier at MARC-order time. This bug is to add a fallback in Koha::EDI's invoice processing: when RFF+LI does not resolve to an aqorders row, attempt to match the invoice line to an order via RFF+SLI (orderline_reference_number) against aqorders.suppliers_reference_number. Depends on bug 43534. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43534 [Bug 43534] Allow MarcFieldsToOrder to map a MARC field to supplier's reference number/qualifier -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 43498] New: UNIMARC: authority search returns no results when the authority type is only in 942$a
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43498 Bug ID: 43498 Summary: UNIMARC: authority search returns no results when the authority type is only in 942$a Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: kdask(a)altsol.gr QA Contact: testopia(a)bugs.koha-community.org Depends on: 41795 Target Milestone: --- Bug 41795 added the completeness attribute (@attr 6=3) to the authtype clause in C4::AuthoritiesMarc::SearchAuthorities. Complete-field matching resolves against Zebra's phrase ('p') register. The UNIMARC authority index definitions build the authtype index from two places: - 152$b -> authtype:w authtype:p - 942$a -> authtype:w (word register only) On UNIMARC installations whose authority records carry the authority type in 942$a only (no 152 coded data field -- common in real-world UNIMARC sites), the authtype phrase register is empty, so every type-filtered authority search returns zero results. In particular, the authority finder launched from the bibliographic editor (e.g. on field 600) always passes an authtypecode, so cataloguers cannot search or link authorities at all. We hit this on three independent production UNIMARC installations (different servers, different Koha and Zebra builds) immediately after upgrading to releases containing Bug 41795 (26.05.00 / 25.11.05). On all of them nearly all authority records have the type in 942$a and no 152$b. Reproduced on current main with KTD (unimarc flavour, Zebra 2.2.8): 1) Create an authority whose type is in 942$a only; full authorities reindex. 2) Authority search with a type filter -> 0 results; the same search without a type filter finds the record. 3) yaz-client against the authority socket confirms the mechanism: @attr 1=authtype @attr 5=100 @attr 6=3 <value> -> 0 hits @attr 1=authtype @attr 5=100 <value> -> 1 hit The Bug 41795 follow-up ("add a phrase Zebra index for 'authtype'") fixed exactly this for MARC21 after the Jenkins failures, but the UNIMARC definitions were not updated (their 152$b block already had a :p index, which masked the 942$a case). The patch (to be attached) applies the same one-line change to the UNIMARC definitions: add authtype:p to the 942$a block in authority-koha-indexdefs.xml, with the regenerated authority-zebra-indexdefs.xsl. A full authorities reindex is required after applying -- worth flagging prominently if this gets backported (cf. Bug 41795 comment 19). Elasticsearch is not affected. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41795 [Bug 41795] UNIMARC: a Zebra search for Corporate Body Name authorities will also return Collective Titles -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 43443] New: Terminology: Issued should be "Checked out" in bookings
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43443 Bug ID: 43443 Summary: Terminology: Issued should be "Checked out" in bookings Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Keywords: Academy Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Found while translating: koha-tmpl/intranet-tmpl/prog/en/modules/bookings/list.tt: issued: () => _("Issued"), koha-tmpl/intranet-tmpl/prog/en/modules/bookings/list.tt: { status: _("Issued"), class: "bg-info" }, Confirmed on Mattermost that "Issued" here means "Checked out", so we should change it to that :) -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 43799] New: cart_to_shelf cron waits an extra hour to update items
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43799 Bug ID: 43799 Summary: cart_to_shelf cron waits an extra hour to update items Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Depends on: 43546 Target Milestone: --- The cart to shelf cron says: --hours | -h The number of hours that need to pass before the location is updated. But it's query is: SELECT itemnumber FROM items WHERE location = 'CART' AND TIMESTAMPDIFF(HOUR, items.timestamp, NOW() ) > ? TIMESTAMPDIFF returns the number of full hours between two times. This means that if I give the cron a parameter of 1, my item will not update until it's been 2 full hours since the item was returned. Assume the item was returned at 8:00 and I've given the cron a parameter of --hours 1 At 8:59, TIMESTAMPDIFF(HOUR, items.timestamp, NOW()) = 0 At 9:00, TIMESTAMPDIFF(HOUR, items.timestamp, NOW()) = 1 At 9:59, TIMESTAMPDIFF(HOUR, items.timestamp, NOW()) = 1 at 10:00, TIMESTAMPDIFF(HOUR, items.timestamp, NOW()) = 2 -- it's finally greater than 1 and my item updates Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43546 [Bug 43546] Standardize command-line scripts on Getopt::Long::Descriptive for safer, more consistent option handling -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 43393] Batch patron modification only saves the changes for shown entries
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43393 ayoung <ayoung(a)oslri.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ayoung(a)oslri.net -- You are receiving this mail because: You are watching all bug changes.

1 0