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

[Bug 41758] New: Add Fingerprint Identifier data to Elasticsearch index mappings
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41758 Bug ID: 41758 Summary: Add Fingerprint Identifier data to Elasticsearch index mappings Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: januszop(a)gmail.com Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Libraries cataloguing older monographic resources request fingerprint indexing. In MARC 21, it would be the content of field 026, in UNIMARC - 012. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 43117] New: t/Form_MessagingPreferences.t does not use Test::NoWarnings
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43117 Bug ID: 43117 Summary: t/Form_MessagingPreferences.t does not use Test::NoWarnings Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 34776 Target Milestone: --- From commit 6cc683b518223479f0c427a8305071fbd9581b5e Bug 34776: Unit tests -use Test::NoWarnings; -use Test::More tests => 2; +use Test::More tests => 1; +use Test::MockModule; +#use Test::NoWarnings; Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34776 [Bug 34776] Patron messaging preferences are lost when an error occurs during new account creation -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 42993] New: Koha::Edifact::Transport should log transport failures via Koha::Logger
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42993 Bug ID: 42993 Summary: Koha::Edifact::Transport should log transport failures via Koha::Logger Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing 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::Transport reports every transport failure (no transport configured, connect failure, directory-change failure, file-listing failure and per-file download/upload failure) with carp. Under misc/cronjobs/edi_cron.pl these go to STDERR, so on a normal cron run the messages are lost: EDI simply goes quiet with nothing in editrace.log to explain why. This routes those failures through Koha::Logger on the 'edi' interface (the same interface edi_cron.pl already uses) so they are recorded in the EDI log. The two ingest()-level data warnings (duplicate filename, unreadable file) are intentionally left as carp: one is asserted by the existing unit test and neither is a transport failure. No change to the transfer logic. Test plan: 1. prove t/db_dependent/Koha/Edifact/Transport.t 2. Point an EDI account at an unreachable transport and run misc/cronjobs/edi_cron.pl; confirm the failure is now written to the EDI log rather than only to STDERR. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 42722] New: Improve invalidPickupBranch error message
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42722 Bug ID: 42722 Summary: Improve invalidPickupBranch error message Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com See Bug 41879 which fixes an issue where a hold can be moved to a bib owned by a branch that doesn't allow pickup at the original hold pickup location. The current error message reads: "Target item/record is an invalid pickup location". This is a bit awkward as it says the item/record _is_ a location. I'll brainstorm some other possibilities below. "Target item/record would have an invalid pickup location" "Hold is unable to be fulfilled using its original pickup location" Or something that tells you how to address the underlying issue? "Target item/record would have an invalid pickup location. Please move the hold to a different item/bib or change the pickup location of the hold to a valid one." I realize the last is the most verbose, but I do like the idea of providing solutions with the error message. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 42685] New: Capitalization: Supplying Agency Request ID and others
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42685 Bug ID: 42685 Summary: Capitalization: Supplying Agency Request ID and others Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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 Found while translating main: Supplying Agency Request ID koha-tmpl/intranet-tmpl/prog/js/vue/components/ILL/SupplyingResource.vue:940 Requesting Agency koha-tmpl/intranet-tmpl/prog/js/vue/components/ILL/SupplyingResource.vue:947 Requesting Agencies koha-tmpl/intranet-tmpl/prog/js/vue/routes/ill.js:73 Requesting Agency Request ID koha-tmpl/intranet-tmpl/prog/js/vue/components/ILL/SupplyingResource.vue:1000 -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 42653] New: ILL request with log entries from multiple backends causes 500 error
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42653 Bug ID: 42653 Summary: ILL request with log entries from multiple backends causes 500 error 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 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 42013] New: Confirmation dialog for "Remove all reserves" never shown on course details page
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42013 Bug ID: 42013 Summary: Confirmation dialog for "Remove all reserves" never shown on course details page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org On the course details page (course_reserves/course-details.tt), clicking "Remove all reserves" skips the confirmation dialog and immediately submits the form. The "Remove all reserves" button (#rm_items_button) is an <a> tag separate from the #rm_items form. The click handler on the button calls $("#rm_items").submit() programmatically. A separate $("#rm_items").click(...) handler was intended to show a confirmDelete dialog, but it is bound as a click event on the form element, which is never clicked by the user. jQuery's .submit() method also does not trigger click events, so the confirmation is never shown. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 41742] New: Use of uninitialized value in repeat (x)... warning in acqui-home.pl
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41742 Bug ID: 41742 Summary: Use of uninitialized value in repeat (x)... warning in acqui-home.pl 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: roman.dolny(a)jezuici.pl QA Contact: testopia(a)bugs.koha-community.org The warning: [WARN] Use of uninitialized value in repeat (x) at /kohadevbox/koha/acqui/acqui-home.pl line 137 appears in the plack-intranet-error.log when entering into Acquisitions module. To reproduce in ktd: 1. Observe plack-intranet-error.log. 2. In staff interface go to Acquisitions module. 3. Warning appears in plack-intranet-error.log. It seems that the "depth" key in: sprintf( "%s", ">" x $$budget{depth} . $$budget{budget_name} ); has not been set previously. Several uses of "depth" are in the "CheckBudgetParentPerm" sub, which is probably not called anywhere. This part of the code is responsible for displaying indents in the list of budgets and funds in the "Fund" drop-down of the Acquisitions module. So maybe it should be the "budget_level" key or "CheckBudgetParentPerm" should be called? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 41445] New: Wrong info about holds selection after hold suspending
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41445 Bug ID: 41445 Summary: Wrong info about holds selection after hold suspending Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: roman.dolny(a)jezuici.pl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com After suspending a hold at patron's holds tab, incorrect information about holds selection is displayed. To reproduce: 1. Have unsuspended hold(s). 2. Go to patron's account, "Details" or "Check out", and "Holds" tab. 3. Click "Suspend" button in "Suspend?" column and confirm modal. 4. Notice: 4.1 checked header checkbox (first column) - not correct, checkbox(es) below are not checked 4.2 number of holds selected in line below the holds table - not correct, checkbox(es) above are not checked, buttons "Cancel selected" and "Suspend selected" are active -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 83

[Bug 41318] New: AmazonLocale system preference - add Brazil as an option
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41318 Bug ID: 41318 Summary: AmazonLocale system preference - add Brazil as an option Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org See the post on Mattermost chat https://chat.koha-community.org/koha-community/pl/7mr33cigziruzpjsutpy97acka on 27 November 2025: amandap Hello Kohers <3, I would like to propose an enhancement to the AmazonLocale System Preference to include Brazil (amazon.com.br) as a selectable option. Currently, the system preference does not list a Brazilian locale. Brazilian libraries using Koha are forced to select the US (amazon.com) or another locale, which results in a low cover image match rate for Brazilian Portuguese editions, as our editions often differ significantly from those listed in other Amazon stores. Including amazon.com.br would significantly improve the accuracy of cover images displayed on the OPAC and Staff Interface for libraries operating in Brazil and potentially other Portuguese-speaking countries, enhancing the value of the Enhanced Content feature for this region. Thank you for considering this enhancement. -- You are receiving this mail because: You are watching all bug changes.

1 23