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

[Bug 39904] New: EDIFACT error messages are malformed
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39904 Bug ID: 39904 Summary: EDIFACT error messages are malformed Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor 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 Perl can interpolate hashrefs but not method calls. This results in messages like "Cannot connect to Koha::Schema::Result::VendorEdiAccount=HASH(0xaaab059252f0)->host: Name or service not known: My Test at ./misc/cronjobs/edi_cron.pl line 58." when running the edi_cron.pl cronjob. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 41528] New: Import EDI invoices without changing to received status
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41528 Bug ID: 41528 Summary: Import EDI invoices without changing to received status Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lhilleary(a)wrl.org QA Contact: testopia(a)bugs.koha-community.org It would be ideal if we could import an EDI invoice without everything automatically reverting to received. If we could just have an invoice arrive for a specific shipment, import it, and then go through to check off each item that is received in the shipment, that would be better. Right now, we have the setting to not import automatically to avoid status changes to newly acquired before we even get the items; now, we manually import. However, even doing this presents a problem as once received, the price cannot be changed without un-receiving a title if needed and location information is not visible (when ordering multiple copies of a title for multiple branches). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[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 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 42077] New: Move RabbitMQ from mandatory to optional and make SQL polling the default
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42077 Bug ID: 42077 Summary: Move RabbitMQ from mandatory to optional and make SQL polling the default Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 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 Depends on: 41506 On bug 41506 we discussed the option of removing RabbitMQ from the codebase. There appears to be consensus that a sensible first step is to update packages to make RabbitMQ optional and SQL polling the default. I believe this would still allow libraries to use RabbitMQ and even move it to a separate server without it installing on the Koha server. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41506 [Bug 41506] Should we remove RabbitMQ? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[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 39118] New: Make facet labels translatable
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39118 Bug ID: 39118 Summary: Make facet labels translatable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Bug 35138 made adding or modifying facets much easier. However, and it was pointed out at the start of the bug report, user-created facets (or user-modified facets) aren't translatable. It would be great if we could have a way of translating them (without using the JS hack). To recreate: 1. Make sure your installation is using ElasticSearch (if using ktd, do `ktd --es7 up` or `ktd --es8 up`) 2. Make sure your installation has at least two languages 2.1. Install new language ktd --shell --root koha-translate --install fr-CA --dev kohadev 2.2. Go to Administration > System preferences 2.3. Search for languages 2.4. Check the new language in OPACLanguages and StaffInterfaceLanguages 2.5. Click 'Save all I18N/L10N preferences' 3. Add a facet (for example, Genre/Form on 655$a in MARC21) 3.1. Go to Administration > Search engine configuration (Elasticsearch) 3.2. In the 'Search fields' tab, find index-term-genre 3.3. Change the label to 'Genre/Form' 3.4. Click 'Save' 3.5. Go to the 'Bibliographic records' tab 3.6. In the last row of the 'Facet order' table, choose 'index-term-genre' 3.7. Click 'Add' 3.8. Click 'Save' 3.9. Go to the 'Bibliographic records' tab again 3.10. Find index-term-genre and change 'Facetable' to 'Yes' 3.11. Click 'Save' 4. Reindex ktd --shell ./misc/search_tools/rebuild_elasticsearch.pl -b -v -d (DO NOT USE -r or all your work in step 3 will be lost :((( ) 5. Search for "comedy" in the staff interface catalog --> The new facet is there with its label "Genre/Form" 6. Switch the interface to the other language 7. Redo step 5 --> The new facet's label is not translated 8. Search for "comedy" in the staff OPAC catalog --> The new facet is there with its label "Genre/Form" 9. Switch the OPAC to the other language 10. Redo step 8 --> The new facet's label is not translated Note: "Hardcoded" facets, such as Authors, Topics, etc. are currently translatable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10