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

[Bug 39557] New: Normalize MARC21 XML metadata into structured MySQL database tables via Koha Plugin
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39557 Bug ID: 39557 Summary: Normalize MARC21 XML metadata into structured MySQL database tables via Koha Plugin Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)trust-box.at QA Contact: testopia(a)bugs.koha-community.org The proposed plugin (Koha::Plugin::HKS3::NormalizeMARC2DB) aims to normalize MARC21 XML metadata from the biblio_metadata.metadata table into structured MySQL database tables. Currently, MARC21 XML is stored as a single XML blob, making advanced querying, reporting, and integration difficult. This plugin introduces an automatic normalization step triggered by the after_biblio_action hook whenever metadata is added or modified. It splits MARC XML into normalized relational tables fully supporting repeatable fields, subfields, and indicators. Advantages: Significantly simplifies complex querying and reporting of MARC21 data. Enhances data integrity and consistency. Facilitates integration with external reporting tools, analytics, and applications. Improves database performance for MARC metadata queries. Provides clear and structured access to MARC data elements. This approach aligns with best practices for database normalization and can substantially enhance Koha's extensibility and interoperability. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 42164] New: Add bibliographic search via database (maybe to replace Zebra)
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42164 Bug ID: 42164 Summary: Add bibliographic search via database (maybe to replace Zebra) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: mark(a)hofstetter.at QA Contact: testopia(a)bugs.koha-community.org create a prototype "to search" for bibliographic records using only the database search is implemented here https://github.com/HKS3/koha-nm2db-keyword-search using (which has to be installed first!) https://github.com/HKS3/koha-normalize-marc2db work in progress / prove of concept -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 17656] New: Irregularities in serial prediction pattern are planned only for the current year
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17656 Bug ID: 17656 Summary: Irregularities in serial prediction pattern are planned only for the current year Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P2 Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com When you se, through test prediction pattern, a serial pattern including planned irregularities (for example a 1/month serial that you know there's no issue on july), this is only valid fot the current subscription. Over the next renewal, you will have to set it again which is very tedious. We should be able to configure this in the long run (as it was possible in previous version of Koha before 3.14, I think) Olivier Crouzet -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 420

[Bug 43879] New: AddReturn does not reindex the record when a withdrawn item blocks the return after clearing onloan
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43879 Bug ID: 43879 Summary: AddReturn does not reindex the record when a withdrawn item blocks the return after clearing onloan Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- In AddReturn, if the item is not checked out but has items.onloan set (inconsistent data), onloan is cleared with skip_record_index, as the record is reindexed at the end of the function. But if the item is withdrawn and BlockReturnOfWithdrawnItems blocks the return, AddReturn returns early, before reaching that reindex. The database no longer has onloan, but the search index still has it, so the search results keep showing the item as checked out. With RecordLocalUseOnReturn enabled the record happens to be reindexed, because the localuse store does not skip the indexing. Without it, nothing is reindexed. The Wrongbranch early return a few lines below already reindexes the record before returning. To reproduce: 1. Enable BlockReturnOfWithdrawnItems and disable RecordLocalUseOnReturn. 2. Take an item that is not checked out, set it as withdrawn and set items.onloan (e.g. UPDATE items SET onloan = CURDATE() WHERE itemnumber = X), and reindex its record. 3. Search the catalog: the item is shown as checked out. 4. Check the item in. The return is blocked (item withdrawn). 5. items.onloan is now NULL, but the search results still show the item as checked out. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 43885] New: Elasticsearch: sorting on a field without a sort mapping makes the whole search fail
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43885 Bug ID: 43885 Summary: Elasticsearch: sorting on a field without a sort mapping makes the whole search fail Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- QueryBuilder::_sort_field appends "__sort" to the sort field without checking that such a field exists in the index. When a field used for sorting (call number, author, title, date of acquisition, popularity...) is configured as not sortable, or is not mapped at all, Elasticsearch rejects the whole query: No mapping found for [cn-sort__sort] in order to sort on and Koha shows "You did not specify any search criteria" / "Unable to perform your search". If defaultSortField or OPACdefaultSortField points to that field, every search fails. The code was meant to handle fields without a sort mapping (sorting on their .raw version for text fields), but that branch is never reached: get_elasticsearch_mappings only records sortable fields in sort_fields, so a field that is not sortable is indistinguishable from an unknown field, and both get "__sort" appended. The existing tests did not catch it because they mock sort_fields with explicit 0 values. To reproduce: 1. Administration > Search engine configuration (Elasticsearch): set "Sortable" to No for cn-sort and save. 2. Rebuild the index so that the mapping is recreated: misc/search_tools/rebuild_elasticsearch.pl -d -b 3. Search the staff interface and sort by call number: the search fails. 4. Set OPACdefaultSortField to "call number": every OPAC search fails. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 43600] New: Strange behavior with Booking dates when editing a booking
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43600 Bug ID: 43600 Summary: Strange behavior with Booking dates when editing a booking Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- TO recreate: 1. Make an item, or item type, bookable. 2. Create a booking 3. Edit the booking 4. Notice strange behavior with the Booking dates. Sometimes you see them correctly, sometimes the field is empty. Usually the dates appear for a second and then disappear. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 42868] New: Bookings are storing incorrect timezone values
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42868 Bug ID: 42868 Summary: Bookings are storing incorrect timezone values Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Somehow, between the date picker and the DB, the bookings module is converting dates incorrectly and setting the wrong dates. To recreate: 1 - Edit koha-conf.xml 2 - Set timezone: <timezone>America/New_York</timezone> 3 - In Koha, enable bookings syspref 4 - Find a record, click the items tab, make an item bookable 5 - Place new booking, choose a date range 6 - View the bookings tab - note the booking extends into the date before 7- Check the DB: MariaDB [koha_kohadev]> select * from bookings WHERE booking_id=2; +------------+-----------+-----------+---------+-------------------+---------------------+---------------------+---------------------+---------------------+--------+---------------------+ | booking_id | patron_id | biblio_id | item_id | pickup_library_id | start_date | end_date | creation_date | modification_date | status | cancellation_reason | +------------+-----------+-----------+---------+-------------------+---------------------+---------------------+---------------------+---------------------+--------+---------------------+ | 2 | 12 | 437 | 971 | FPL | 2026-06-23 20:00:00 | 2026-06-26 19:59:59 | 2026-06-17 15:00:40 | 2026-06-17 15:00:40 | new | NULL | +------------+-----------+-----------+---------+-------------------+---------------------+---------------------+---------------------+---------------------+--------+---------------------+ 1 row in set (0.000 sec) Start date time is 20:00 - really 00:00 minus 4 - New York is UTC minus 4 - it seems we shouldn't subtract more -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 40999] New: Tie checkout of an itemtype to a patron attribute
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40999 Bug ID: 40999 Summary: Tie checkout of an itemtype to a patron attribute Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Many libraries require some variety of agreement form to be signed before patrons can borrow various itemtypes (laptops, hedge trimmers, other items that are expensive or potentially dangerous when misused). Many of these libraries define patron attributes to record whether or not a given patron has signed the relevant agreement is on file. It could be helpful to allow a library to tie an itemtype to a specific patron attribute, blocking checkout of that itemtype to any patron who does not have a "Yes" or 1 in that attribute. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 43220] New: Patron name and card number should not be clickable in headings
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43220 Bug ID: 43220 Summary: Patron name and card number should not be clickable in headings Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 29768 Target Milestone: --- Since Bug 29768 the patron name and card number in the sidebar of patron pages is linked to the patron detail page. On the checkout page the patron name in the main heading is also clickable. This change happened in Bug 29768, "hidepatronname hides guarantor name on borrower edit screen." I think this was unintended and should be considered a bug. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29768 [Bug 29768] hidepatronname hides guarantor name on borrower edit screen -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 43866] New: Patron name and card number should not be clickable in remaining 'Checking out to' headings
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43866 Bug ID: 43866 Summary: Patron name and card number should not be clickable in remaining 'Checking out to' headings 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 43220 Target Milestone: --- Follow-up to Bug 43220, which stopped the patron name and card number being a link in the "Checking out to" label above the barcode input on circ/circulation.pl. Two other "Checking out to" headings still render the patron name and card number as a link, by including patron-title.inc without the no_html flag: 1. koha-tmpl/intranet-tmpl/prog/en/modules/circ/circulation.tt (around line 1060): an <h4> "Checking out to ..." shown inside the warning circmessage when the patron cannot check out (noissues is set, and OnSiteCheckoutsForce is not enabled). 2. koha-tmpl/intranet-tmpl/prog/en/modules/circ/circulation_batch_checkouts.tt (around line 85): the <legend> "Checking out to ..." on the batch checkout page. Pass no_html=1 to patron-title.inc in both places, as Bug 43220 did, so the headings are plain text and consistent with the main checkout form. Test plan: 1. Check out to a patron who is blocked from checking out (for example a restricted or debarred patron) so the warning message with the "Checking out to ..." heading is shown. Note the name and card number are a link. 2. Go to Circulation > Batch check out and select a patron. Note the "Checking out to ..." legend contains a link. 3. Apply the patch and repeat steps 1 and 2. 4. Confirm both headings show the name and card number as plain text, with no link. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43220 [Bug 43220] Patron name and card number should not be clickable in headings -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9