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

[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 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 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

[Bug 43808] New: LocalHoldsPriority follows Transport cost matrix rather than position in queue
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43808 Bug ID: 43808 Summary: LocalHoldsPriority follows Transport cost matrix rather than position in queue Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: klas.blomberg(a)skovde.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- Set LocalHoldsPriority to Give library, then library group Create a local hold group with at least three libraries - the more libraries the better for this test Set UseTransportCostMatrix to Use Enter some values in the Transport cost matrix for the libraries in the hold group Place holds for a title to pick-up on each one of the libraries in the group. Check-in the item at it’s home branch and it fills the hold for the patron on that branch – as expected. Return the item from the first borrower. As there are no more borrowers waiting for the item at the home branch we expect it to go to the first borrower in queue at some other branch in the hold group. Instead it goes to the borrower at the branch with lowest value in the Transport cost matrix, irrespective of what position that borrower has in the queue. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 41240] New: Add configurable hold skip limit to LocalHoldsPriority
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41240 Bug ID: 41240 Summary: Add configurable hold skip limit to LocalHoldsPriority Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: johanna.raisa(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com A new configuration option allows the admin to set the maximum number of times a hold can be skipped. Once this limit is reached, the hold must be prioritized and filled. Improves fairness in hold fulfillment and prevents holds from being ignored due to prioritization. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 41095] New: Allow to limit LocalHoldsPriority filling to a maximum number of holds in the queue
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41095 Bug ID: 41095 Summary: Allow to limit LocalHoldsPriority filling to a maximum number of holds in the queue Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: johanna.raisa(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Libraries want to limit the LocalHoldsPriority filling to match only x number of holds in the queue. If there are 100 holds and they want to allow the LocalHoldsPriority system preference to check only 20 first holds for example. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 39989] New: Expand LocalHoldsPriority groups to allow different settings by group
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39989 Bug ID: 39989 Summary: Expand LocalHoldsPriority groups to allow different settings by group Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 Some libraries would like to be able to set LocalHoldsPriority to be able to have each group set to Group vs Library and Group instead of the same for all groups. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 41506] New: Should we remove RabbitMQ?
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41506 Bug ID: 41506 Summary: Should we remove RabbitMQ? 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org At the hackfest in Wellington this came up as a question in the discussion and it was decided to bring it up at the next development meeting. https://koha-hedgedoc.servers.llownd.net/Development_IRC_meeting_26_Novembe… The discussion is difficult and we want to include as many opinions/people as possible. I felt it would be a bit lost on bug 35920, so proposing a separate bug report instead. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 38

[Bug 43806] New: Add ability to prefork the Z39.50/SRU responder ( z3950_responder.pl ) with a maximum number of children
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43806 Bug ID: 43806 Summary: Add ability to prefork the Z39.50/SRU responder ( z3950_responder.pl ) with a maximum number of children Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Currently the z3950_responder.pl hands its accept loop to the YAZ frontend server through Net::Z3950::SimpleServer. YAZ forks a new child for every connection and has no limit on how many children it will create. Each child is a full Koha Perl process, so a burst of connections, or a pile of idle sessions held open until the idle timeout ( 60 minutes by default ), can use up all the memory on a server! It would be good to be able to cap concurrent sessions and keep a pool of preforked workers, the same way the SIP server does with Net::Server::PreFork. YAZ can serve a single connection in inetd mode ( -i ) and then return control to Perl, so Net::Server::PreFork can own the listening socket and each child can hand its accepted connection to YAZ. Each child serves one session and then exits. We should add the following options to z3950_responder.pl, settable through z3950_responder_options in the instance's z3950/config.xml: * --max-servers ( enables preforking ) * --min-servers * --min-spare-servers * --max-spare-servers Without --max-servers the responder should behave exactly as it does today. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0