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

[Bug 42909] New: Suspend class missing from suspended holds on request.pl
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42909 Bug ID: 42909 Summary: Suspend class missing from suspended holds on request.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Depends on: 23269 Target Milestone: --- When viewing the holds list for a particular biblio record, the tr (table row) elements previously had a "suspend" class, allowing CSS styling of suspended holds. As of 25.11.05, that class is missing. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23269 [Bug 23269] Long hold queues are slowing the service -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 40610] New: Update OPAC templates to improve east of translation
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40610 Bug ID: 40610 Summary: Update OPAC templates to improve east of translation Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com Looking at [lang]-opac-bootstrap.po I see a lot of instances of repeated %s %s %s indicating opportunities to improve the markup structure to ease the translation process. This patch will tackle a batch of include files: koha-tmpl/intranet-tmpl/prog/en/includes/item-status.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/biblio-title-head.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/biblio-title.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/date-format.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/holds-table.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/masthead.inc -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 38621] New: [% today %] variable unavailable in report templates
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38621 Bug ID: 38621 Summary: [% today %] variable unavailable in report templates Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I tried adding a date to a report template, but it doesn't seem to work. I was told on MM that this is a bug. To recreate: 1. Create a report notice template with [% today %] 1.1. Go to Tools > Notices and slips 1.2. Click New notice > Reports 1.3. Enter a code and a name 1.4. Click Email 1.5. Enter a subject 1.6. In the message body, add some info with [% today %], here is what I used [% USE KohaDates %] [% today | $KohaDates %] [% FOREACH d IN data %] [% d.title %] [% END %] 1.7. Click Save 2. Create a report that works with this template 2.1. Go to Reports > Create from SQL 2.2. Enter a report name 2.3. In the SQL field, enter a report that would work with the template, this is what I used SELECT * from biblio limit 1 2.4. Click Save report 3. Click Run with template > Template name --> The date doesn't appear I also tried with a the simple [% today %] without the USE and without the KohaDates filter, but it doesn't show the date either. If I don't put the USE but use the filter, the template simply doesn't work (when you click Run with template > Template name, the report is displayed as normal in table form). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 40603] New: Add support for "uri" to OPACAuthorIdentifiersAndInformation
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40603 Bug ID: 40603 Summary: Add support for "uri" to OPACAuthorIdentifiersAndInformation Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org It could be nice to support 024$2 uri with the OPACAuthorIdentifiersAndInformation system preference, to display the information in OPAC and staff. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 42771] New: Change icon used in installer to represent unfinished steps
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42771 Bug ID: 42771 Summary: Change icon used in installer to represent unfinished steps Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 42564 Created attachment 199902 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199902&action=e… Before (left) and after (right) I think I made a poor choice in using a black box icon in the web installer to represent unfinished steps. They look too much like HTML checkboxes. I think this dotted box is more clear. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42564 [Bug 42564] Upgrade Font Awesome in the staff interface to 7.2 -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 42564] New: Upgrade Font Awesome in the staff interface to 7.2
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42564 Bug ID: 42564 Summary: Upgrade Font Awesome in the staff interface to 7.2 Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 34973 Building on Bug 34973, we should upgrade Font Awesome in the staff interface to 7.2. Besides helping to keep assets up to date this fixes the constant "downloadable font: Glyph bbox was incorrect" warnings in the browser console. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34973 [Bug 34973] Update Font Awesome to fix JS warning in the console for Firefox: "Glyph bbox was incorrect" -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 39727] New: Remove DelSuggestionsOlderThan from C4/Suggestions.pm
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39727 Bug ID: 39727 Summary: Remove DelSuggestionsOlderThan from C4/Suggestions.pm Change sponsored?: --- 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: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org See https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23990 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 28915] New: MARC Modification Templates should allow specification of a position or range within a control field
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28915 Bug ID: 28915 Summary: MARC Modification Templates should allow specification of a position or range within a control field Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When dealing with the MARC Leader, 008, and other fixed length control fields, it would be nice to be able to make the modification templates look at, match on, and alter only a specific position or range. For example, suppose I have several records in which I want to change the 008 position 33 (Literary form) from a 0 to a 1 (nonfiction to fiction). Currently I could tell my modification template to update the 008 of every record I point it at where the character in position 33 is a 0 (using regex to match only that specific character). But then there's no way to change ONLY that character and preserve the rest of the field. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 144

[Bug 43055] New: HTML customizations adds a white background
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43055 Bug ID: 43055 Summary: HTML customizations adds a white background Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- HTML customizations includes a white background which is not always wanted. Is this intentional, or can it be shut off? It would be easy to add to content if needed, but is more difficult to remove if it isn't needed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 42948] New: Diacritics corrupted when saving authority records (UTF-8 mangled into unrelated Unicode characters, e.g. é→ř, ú/ñ→ž)
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42948 Bug ID: 42948 Summary: Diacritics corrupted when saving authority records (UTF-8 mangled into unrelated Unicode characters, e.g. é→ř, ú/ñ→ž) Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: PC OS: Linux Status: NEW Severity: major Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: 328807(a)unizar.es QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Created attachment 201329 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201329&action=e… Attachments included: 1 Screenshot of authority before save (correct name) 2 Screenshot of authority after save (corrupted name) 3 Screenshot showing the same corruption when typed When creating or saving an authority record containing accented characters (e.g. Spanish names with á, é, í, ó, ú, ñ), the diacritics are corrupted into unrelated Unicode characters upon save. The corruption pattern is not simple mojibake (e.g. "Ã©") but rather diacritics merging with adjacent letters into different Unicode characters, including letters from other alphabets (e.g. ř, ž, ø, æ). Example: Correct name: "Pérez Zúñiga, Juan" After saving the authority in Koha: "Přez Žiga, Juan" Correct name: "García-Posada, Miguel" After saving: "Garcá-Posada, Miguel" (character dropped entirely) Steps to reproduce: Go to Authorities module. Create a new authority manually (New authority), entering a personal name with accented characters directly in field 100 $a (e.g. "Hierro, José" or "Pérez Zúñiga, Juan"). Save the record. Reopen the saved authority record. Observe that the accented characters have been replaced/corrupted. This reproduces even when the authority is created entirely manually, without using Z39.50/SRU import, ruling out any Z39.50 target encoding issue. Troubleshooting already performed (ruling out other causes): Confirmed the issue is NOT related to the Z39.50/BNE server encoding: tested with UTF-8, MARC-8, ISO-5426, ISO-8859-1 and ISO_6937 encodings on the Z39.50 target — all produce different (but still wrong) corruption patterns, and the corruption also occurs when manually typing the authority without using Z39.50 at all. Confirmed the Leader position 09 (Character coding scheme) of the bibliographic record is correctly set to "a" (UCS/Unicode), auto-filled. Confirmed the same corruption occurs when importing the same correct UTF-8 data from a different Z39.50 target (Library of Congress Names), which displays the name correctly in the search results list, but the data is still corrupted once saved as a Koha authority — pointing to the save process itself, not the data source. Confirmed database-level encoding is correctly configured throughout: Database: utf8mb4 / utf8mb4_uca1400_ai_ci Table auth_header: column marcxml is longtext with collation utf8mb4_unicode_ci MySQL/MariaDB session variables (character_set_client, character_set_connection, character_set_database, character_set_results, character_set_server) all set to utf8mb4 collation_connection, collation_database, collation_server all utf8mb4_uca1400_ai_ci Given the above, the corruption appears to originate in the Koha application layer (Perl/Plack) during the authority save process, rather than in any Z39.50 target configuration or in the database encoding configuration. Environment: Koha version: 26.05.00 Database: MariaDB (utf8mb4, collation utf8mb4_uca1400_ai_ci) Authority framework: MARC21 PERSO_NAME Attachments included: • Screenshot of authority before save (correct name) • Screenshot of authority after save (corrupted name) • Screenshot showing the same corruption when typed manually (no Z39.50 involved) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13