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

[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

[Bug 43887] New: Checkout warning block has empty id instead of circmessages
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43887 Bug ID: 43887 Summary: Checkout warning block has empty id instead of circmessages 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: 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: 38714 Target Milestone: --- On the checkout page (circ/circulation.pl), the block that holds the "Cannot check out!" warning (and the on-site-checkouts-only attention message) should have id="circmessages". Since Bug 38714 it renders id="" instead. circulation.tt sets a variable div_id to 'circmessages' in each branch, but the div is then written as: <div id="[% circmessages | html %]" class="[% div_class | html %]"> i.e. it outputs the (undefined) variable circmessages instead of div_id. Consequences: - Custom IntranetUserCSS / IntranetUserJS that target #circmessages (it worked up to 24.11) no longer match. - The staff stylesheet rule for #circmessages (card styling: padding, bottom margin, white background) no longer applies to this block. With the id the block has 1rem padding, 1rem bottom margin and a white background; without it, 0.4rem padding, no margin and a transparent background. - The page emits an invalid empty id attribute. Affects 25.05 and later, including main. Test plan: 1. Have a patron who cannot check out (for example add a manual restriction to a patron). 2. Go to the checkout page for that patron. 3. Inspect the "Cannot check out!" block: the div has id="" and no card styling (no white background, tight padding). 4. Apply the patch and reload. 5. The div now has id="circmessages", and it has padding, bottom margin and a white background. 6. Optionally enable OnSiteCheckouts and OnSiteCheckoutsForce and confirm the attention variant also has id="circmessages". Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38714 [Bug 38714] Adjust templates for prettier -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 43672] New: When a patron has no advance notices value and their category is changed to one with a value the checkboxes are not enabled
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43672 Bug ID: 43672 Summary: When a patron has no advance notices value and their category is changed to one with a value the checkboxes are not enabled Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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, kyle(a)bywatersolutions.com Target Milestone: --- To recreate: 1 - Have two patron categories one with messaging preference default with advance notices days and email set one with no messaging preference defaults 2 - Save a patron in the category with no defaults 3 - Edit the patron, change their category to the one with a default 4 - Note the checkbox for email is disabled, but days dropdown is set 5 - Save 6 - Note the patron has days set, but no transport -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 43249] New: A duplicate report limit of 1 prevents users from running reports at all
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43249 Bug ID: 43249 Summary: A duplicate report limit of 1 prevents users from running reports at all Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Target Milestone: --- The code that checks runnign reports checks: $running >= $duplicate_limit, but it appears a report is marked as running during prep_report Additionally Koha::Reports->running returns the reports instances, and not a count - we need to call count on the result -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 42697] New: Home library and current library filters can filter incorrectly
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42697 Bug ID: 42697 Summary: Home library and current library filters can filter incorrectly 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 To recreate: 1. Create two branches in Koha a. Bearville ( code: BEA ) b. Beachville ( code: BCH ) 2. Find a record and create some items for the BCH branch 3. Now on the record detail page, click Show filters 4. Filter by the Bearville branch ( which should have no items ) for Current library or Home library 5. Notice it filters out everything except the Beachville items -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 43