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

[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 43757] New: EDIFACT parser drops syntax 4 interchanges silently and dies on a missing UNA
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43757 Bug ID: 43757 Summary: EDIFACT parser drops syntax 4 interchanges silently and dies on a missing UNA 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::Edifact::service_string_advice only accepts the exact string ":+.? '" and the failure paths are silent or fatal: 1. An interchange using syntax version 4 service characters, for example UNA:+.?*' , is not accepted. In syntax version 3 the fifth UNA character is reserved (a space); in syntax version 4 it is the repetition separator (default asterisk). Koha does not use repetition, so it can simply be ignored, but at present the file is thrown away. Result on main: the parser only carps "Non standard Service String Advice", Koha::Edifact->message_array returns 0 messages, process_invoice (and process_quote / process_ordrsp) then mark the message 'received' having done nothing. An invoice is lost without any error being shown to staff. 2. An interchange that does not start with UNA makes Koha::Edifact->new croak ("File does not start with a Service string advice"). The calls in edi_cron.pl are not wrapped, so the whole cron run stops: the remaining messages and accounts are not processed and the message is left in status 'processing'. Reproduced on main with a minimal interchange: - UNA:+.?*' -> messages = 0, warning only - no UNA -> dies References: ISO 9735 service string advice as profiled for syntax versions 3 and 4 (for example Odette OS11 "Structure of an EDIFACT Interchange", sections 2.2 and 4, and GS1 EANCOM syntax documentation). Note that for character sets other than UNOA/UNOB the default separators are non-printable, so a sender using printable separators is required to send UNA; a missing UNA is therefore a supplier-side error rather than something Koha should guess at. Proposed changes: a. Accept the syntax 4 service string advice by ignoring position 5, and keep refusing separators Koha cannot handle. b. When an interchange cannot be parsed, or parses to no messages, set the edifact_messages status to 'error', add an edifact_errors row with the reason, and carry on with the next message instead of marking it received or dying. (Optionally, as a follow-up, assume the standard separators when UNA is absent.) Test plan: 1. Add an INVOIC message whose interchange starts with UNA:+.?*' to edifact_messages and process it. 2. Without the patch: no invoice is created, the message is marked received, and no error is recorded. 3. With the patch: the invoice is created as it would be with UNA:+.? '. 4. Add a message with no UNA and a second, valid message, then run misc/cronjobs/edi_cron.pl (or process_invoice on both). 5. Without the patch: the cron dies on the first message. With the patch: the first message has status 'error' with an edifact_errors row, and the second is processed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 43756] New: EDI invoice processing receives lines for cancelled orders and re-opens them
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43756 Bug ID: 43756 Summary: EDI invoice processing receives lines for cancelled orders and re-opens them 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_invoice receives an invoice line even when the order it refers to has been cancelled in Koha. The cancelled order is received like any other: its status is changed from cancelled to complete, quantityreceived and prices are set, and nothing is recorded in edifact_errors. Bug 38423 made process_invoice skip and report lines that cannot be receipted (no ordernumber, unknown order, deleted record) and its description names cancelled orders as one of the problem cases, but a cancelled order is not skipped. Process_invoice already records a warning for an order that is already complete; a cancelled order gets no such treatment. Reproduced on main (vendor EDI account without plugin): an order with orderstatus 'cancelled' and one linked item, and an invoice for it with QTY+47:1 and RFF+LI pointing to the order. - order status after processing: complete (quantityreceived 1) - edifact_errors: none - message status: received This silently undoes a cancellation (for example one made by staff or by an ORDRSP cancel), re-opens spent budget and gives staff no indication that the supplier invoiced a line the library believed was cancelled. Proposed behaviour: skip the line, leave the order cancelled, and add an edifact_errors row (with the invoice number) saying the invoice line refers to a cancelled order, so staff can reconcile it with the supplier. Test plan: 1. Create an order line and cancel it. 2. Process an EDIFACT invoice that refers to the order with RFF+LI. 3. Without the patch: the order becomes complete and no error is shown. 4. With the patch: the order stays cancelled, other lines on the invoice are still received, and the EDIFACT messages page shows an error for the invoice line referring to a cancelled order. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 43754] New: EDI invoice receipt does not update item acquisition fields like manual receive does
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43754 Bug ID: 43754 Summary: EDI invoice receipt does not update item acquisition fields like manual receive does 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: --- When an EDIFACT invoice is processed, Koha::EDI::receipt_items only assigns a barcode (from GIR LAC) and applies AcqItemSetSubfieldsWhenReceived. It does not touch any of the other fields that the manual receive path sets. Manual receive (acqui/finishreceive.pl) updates every item linked to the received order with: booksellerid, dateaccessioned, datelastseen, price, replacementprice, replacementpricedate EDI receipt sets none of these, so items received through an invoice end up with different data from the same items received by hand: no source of acquisition, an accession date that is still the order date, and no price or replacement price. Reproduced on main with a vendor EDI account (no plugin), a basket with create_items=ordering, an order for 2 copies each with a linked item (dateaccessioned 2020-01-01), and an INVOIC for the 2 copies carrying matching GIR+LLO segments: - order becomes complete, quantityreceived 2 - items: booksellerid NULL, dateaccessioned still 2020-01-01, price NULL, replacementprice NULL Expected: the same item fields as a manual receive, using the invoice date as the received date, the vendor of the basket and the invoiced/replacement prices of the received order. Note this is separate from Bug 42890 (creating items when AcqCreateItem=receiving). Test plan: 1. Create a vendor with an EDI account (no plugin) and a basket with AcqCreateItem=ordering. Add an order line for 2 copies so that 2 items exist. 2. Import an EDIFACT invoice for that order (RFF+LI with the order number, QTY+47:2, MOA+203/MOA+128) and process it. 3. Without the patch: the items have no booksellerid, an unchanged dateaccessioned, and empty price and replacementprice. 4. With the patch: the items have the vendor as booksellerid, dateaccessioned and datelastseen set to the invoice date, price set from the received unit price, and replacementprice/replacementpricedate set as in a manual receive. 5. Repeat with a partial receipt (invoice 1 of 3) and confirm only the received items are updated. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

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 42274] New: opac-tags.pl should return JSON instead of JS script
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42274 Bug ID: 42274 Summary: opac-tags.pl should return JSON instead of JS script 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org koha-tmpl/opac-tmpl/bootstrap/js/tags.js makes AJAX calls to ./opac/opac-tags.pl which returns Javascript scripts rather than JSON. The crazy part is that it's mostly just returning a JSON object anyway. There are some gotchas where it returns a JS object with embedded KOHA.Tags.tag_message() functions, but I'm sure we can fix that. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 43787] New: Adding orders from a staged file ( addorderiso2709.pl ) can use gigabytes of memory if there are many funds
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43787 Bug ID: 43787 Summary: Adding orders from a staged file ( addorderiso2709.pl ) can use gigabytes of memory if there are many funds Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major 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 Target Milestone: --- The page for adding orders to a basket from a staged file has a fund dropdown for each record, and another for each item when MarcItemFieldsToOrder is used. Each dropdown lists every fund from every budget, inactive ones included, and the template loops that build them are so deeply indented that most of the page is whitespace. With about 1,000 funds ( not difficult for a large system that rolls over funds anually ) and a staged file of 140 records and 287 items, the page is 367 MB, 88% of it whitespace, and the Plack worker that renders it peaks at 4.5 GB of memory. To recreate: 1) Create 1,000 funds in an inactive budget 2) Set MarcItemFieldsToOrder to: homebranch: 952$a holdingbranch: 952$b itype: 952$y 3) Stage a file of 140 records with items from Add to basket > From a new file 4) Click "Add staged files to basket" 5) Note the size of the page and the memory used by the Plack worker -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[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 14 Oct '26

14 Oct '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 8

[Bug 43540] New: Switching OPAC language loses /bib/<id> short URLs, redirects to homepage
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43540 Bug ID: 43540 Summary: Switching OPAC language loses /bib/<id> short URLs, redirects to homepage 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 Target Milestone: --- When switching the OPAC interface language on a page reached via Koha's own /bib/<biblionumber> short URL (see the RewriteRule shipped in apache-shared-opac.conf / etc/koha-httpd.conf), the user is redirected to the OPAC homepage instead of staying on the record they were viewing. The same applies on the staff side for /bib/<biblionumber> against catalogue/detail.pl. Root cause: the /bib/ RewriteRule uses the [PT] flag, meaning it is an internal rewrite - the browser's address bar and Referer header keep showing /bib/<id>, never /cgi-bin/koha/opac-detail.pl. Koha::Util::Navigation::local_referer() (used by opac-changelanguage.pl and changelanguage.pl to work out where to send the user back to after a language switch) treats a referer as local only if it matches the site's OPACBaseURL/staffClientBaseURL AND contains the literal substring /cgi-bin/koha/. Since /bib/<id> never contains that substring, local_referer() falls through to its fallback (the site root), so the language switch drops the user on the homepage. This patch extends local_referer()'s recognized local-path pattern to also accept Koha's own /bib/<digits> short URL, in both the OPACBaseURL/staffClientBaseURL branch and the no-base-URL fallback branch. Test plan: 1. Enable mod_rewrite and confirm the /bib/<biblionumber> short URL works for an OPAC record (e.g. /bib/123 loads the same page as opac-detail.pl?biblionumber=123). 2. On that page, switch OPAC language using the language selector in the header or footer. 3. Before this patch: you are redirected to the OPAC homepage, losing the record. 4. After this patch: you are redirected back to /bib/123, now in the newly selected language. 5. prove t/Koha/Util/Navigation.t - all tests pass, including two new /bib/ short url cases. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 41825] New: Holds cannot be cancelled after a checkout on the patron checkout page
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41825 Bug ID: 41825 Summary: Holds cannot be cancelled after a checkout on the patron checkout page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Steps to reproduce: 1- Find two items, A and B, from two different bibliographic records. 2- Place a hold on item A for a patron. 3- Go to the patron Checkout page and check out item B. 4- Click on the Holds tab. 5- Click on the Delete icon to cancel the hold and confirm the cancellation. 6- Go back to the patron Checkout page and open the Holds tab. ---> The hold is not deleted. 7- Check out another item. 8- In the Holds tab, select the hold and click Cancel selected. ---> Nothing happens. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10