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

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

[Bug 34223] New: ILL status filter does not load immediately after selecting a backend filter
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34223 Bug ID: 34223 Summary: ILL status filter does not load immediately after selecting a backend filter Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com CC: pedro.amorim(a)ptfs-europe.com Selecting a backend filter in ILL is required in order for the status filter to become enabled. Once a provider is chosen in the backend filter, it takes the status filter around 7s to populate instead of populating immediately. This is confusing to staff members and can also disrupt the workflow. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59

[Bug 34058] New: ILL - Left filters not considering all terms in input
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34058 Bug ID: 34058 Summary: ILL - Left filters not considering all terms in input Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, katrin.fischer(a)bsz-bw.de, magnus(a)libriotech.no, martin.renvoize(a)ptfs-europe.com, nick(a)bywatersolutions.com, pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com Depends on: 22440 To reproduce, on k-t-d: 1) Run bash <(curl -s https://raw.githubusercontent.com/ammopt/koha-ill-dev/master/start-ill-dev.…) 2) Create a FreeForm ILL request and input 23529000035676 in the cardnumber, that's "Henry Acevedo". 3) Go back to the ILL list table, input "henry" in the bottom "Patron" filter input and press the "Search" button, notice it fetches the request correctly. 4) Now do the the same search but with "henry acevedo", notice the request is not retrieved. The same issue also happens in the "keyword" filter input. Info: patron-search.inc is already doing what we need, but for patrons left side filters, it's handling all the patterns present in the #search_patron_filter input and adding each of those to the query, we need something similar here. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22440 [Bug 22440] Improve ILL page performance by moving to server side filtering -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 44

[Bug 23988] New: When replace record with z39.50, give option on what gets pre-populated
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23988 Bug ID: 23988 Summary: When replace record with z39.50, give option on what gets pre-populated Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently in Koha, when a user chooses to replace an existing record with another record using z39.50, Koha will prepopulate the z39.50 search with Title, Author and ISBN. This search is very constrictive and it would be nice to have the option of what fields get prepopulated instead of having to manually remove the fields that the user doesn't want. Specifically, an ISBN pre-population would be ideal for a library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 42610] New: Modification history and restore modifications
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42610 Bug ID: 42610 Summary: Modification history and restore modifications Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: chris.mathevet(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Added a new page that displays a record’s modification history, with the ability to restore previous states. Test Plan: - Go to a record page - Edit the record (modify, add, or remove fields) - Open “Modification history” from the left navigation bar - Select a state to restore - Verify that the restore preview displays the current record and the changes that will be applied - Click “Restore” - Verify that all modified and unmodified fields are correctly preserved in the record -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 42563] New: Add Koha::Biblio->host_items using MetadataExtractor
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42563 Bug ID: 42563 Summary: Add Koha::Biblio->host_items using MetadataExtractor 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Currently, C4::Items::get_hostitemnumbers_of is the only way to get items linked via MARC 773$9 (MARC21) / 461$9 (UNIMARC) host record fields. This function lives in the C4:: namespace and mixes MARC parsing with DB queries. This bug adds: 1. get_host_itemnumbers method to Koha::Biblio::Metadata::Extractor::MARC::MARC21 and ::UNIMARC â extracts itemnumbers from the appropriate MARC field 2. Koha::Biblio->host_items â convenience method returning a Koha::Items resultset (gated behind EasyAnalyticalRecords syspref) Replaces C4::Items::get_hostitemnumbers_of using the MetadataExtractor pattern from Bug 34828. Callers to migrate: - Koha::Biblio::Availability::Hold (Bug 42386) - C4::ILSDI::Services::HoldTitle - reserve/request.pl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 41566] New: Tidy kohaTable block - catalogue
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41566 Bug ID: 41566 Summary: Tidy kohaTable block - catalogue Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 41