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

[Bug 42679] New: Add GET /patrons/{patron_id}/overdues_count endpoint
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42679 Bug ID: 42679 Summary: Add GET /patrons/{patron_id}/overdues_count endpoint Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Add a new REST API endpoint that returns the count of overdue checkouts for a patron as a plain integer. This endpoint computes the count live from the database (date_due < NOW()) to ensure accuracy, as overdue status is time-based with no discrete event to trigger updates. The primary use case is async loading in the patron search table: the main search results render immediately while overdues are fetched separately per visible page, improving perceived performance. Endpoint: GET /api/v1/patrons/{patron_id}/overdues_count Response: integer (e.g. 3) Permission: borrowers => list_borrowers -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 39890] New: Accessibility: Add more Bypass blocks to the OPAC.
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39890 Bug ID: 39890 Summary: Accessibility: Add more Bypass blocks to the OPAC. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: nina.martinez(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org To improve the Opac accessibility, we can add more bypass blocks to facilitate keyboard navigation (WCAG 2.4.1). Currently, we have one bypass for 'skip to the main content.' We could also add a bypass to skip to the footer, to skip to the search and to skip to the menu for pages that have one. https://www.w3.org/WAI/WCAG21/Understanding/bypass-blocks.html -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 39420] New: Item edit breadcrumbs wrong
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39420 Bug ID: 39420 Summary: Item edit breadcrumbs wrong Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org When you open a record detail view, this is the breadcrumb: ``` Home / Catalog / The title / Details ``` If you choose to edit its items, the breadcrumb becomes: ``` Home / Cataloging / Edit The title (Record # NN) / Items ``` So you cannot actually use the breadcrumb to go back to the detail page for the record, but instead you go to the MARC editor. I believe it should be like this instead: ``` Home / Catalog / The title / Edit items ``` If we wanted to have a shortcut for editing the MARC record, I would add a link in the breadcrumb like this: ``` Home / Catalog / The title ([edit](/the/url))/ Edit items ``` But, right now, it is super weird. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 35052] New: OpacHiddenItemsHidesRecord system preference should be considered on index time instead
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35052 Bug ID: 35052 Summary: OpacHiddenItemsHidesRecord system preference should be considered on index time instead Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: alexander.blanchard(a)ptfs-europe.com, dcook(a)prosentient.com.au, jacob.omara(a)ptfs-europe.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com Currently, results are being skipped after the search has been processed in C4/Search.pm. This may cause several unintended scenarios: 1) The first page has all the results skipped, even thought there are more results in 2nd page and so on, this will will result in a "No search results" page 2) The total search results number still shows 80 (for example), even if it has skipped 70 and is only showing 10. To reproduce we need to use both OpacHiddenItems and OpacHiddenItemsHidesRecord Use OpacHiddenItems and put some rules that hide some items Use OpacHiddenItemsHidesRecord = 'hide' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 42310] New: Move calendar CRUD to Koha::Calendar::* with normalized schema
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42310 Bug ID: 42310 Summary: Move calendar CRUD to Koha::Calendar::* with normalized schema 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 The calendar system currently relies on C4::Calendar for all write operations using raw DBI, and two overloaded tables where column values determine the type of closure (repeatable_holidays.weekday IS NOT NULL = weekly, IS NULL = annual; special_holidays.isexception = closure vs exception). Single dates are stored as separate day/month/year smallints instead of a DATE column. The goal is to replace this with proper Koha::Object classes under the Koha::Calendar::* namespace backed by normalized, purpose-specific tables, and refactor Koha::Calendar to consume them. This unblocks REST API CRUD endpoints and a Vue-based rewrite of the holidays admin page in the future. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 126

[Bug 41995] New: Autocomplete for syspref search
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41995 Bug ID: 41995 Summary: Autocomplete for syspref search Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 41994 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41994 [Bug 41994] REST API route to list system preferences -- You are receiving this mail because: You are watching all bug changes.

1 68

[Bug 43151] New: ES should apply search filters on each item discretely
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43151 Bug ID: 43151 Summary: ES should apply search filters on each item discretely Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 42835 Target Milestone: 26.11 When filtering search results using item record values, Koha checks for each of those values at the biblio level, rather than at the item level. This leads to undesirable search results. For example, assume you have a biblio with two items: - item 1 is itype BOOK and collection FICTION - item 2 is itype AUDIO and collection NONFICTION Currently, if a user performs a search limited to itype=BOOK and collection=NONFICTION, this biblio will be returned because it has at least one BOOK item and at least one NONFICTION item. But the user expectation is that the search will return biblios where at least one item that is both a BOOK and NONFICTION. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42835 [Bug 42835] ElasticSearch should have an items index -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 38638] New: Offer the option to set non-priority option when placing multiple holds
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38638 Bug ID: 38638 Summary: Offer the option to set non-priority option when placing multiple holds Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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: 22789 When placing multiple holds in the staff interface there isn't an option to set the holds as non-priority. As far as I know there's not a technical reason not to include the option? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22789 [Bug 22789] Establish non-priority holds -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 40167] New: Curbside pickups - Show link if not configured
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40167 Bug ID: 40167 Summary: Curbside pickups - Show link if not configured 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Right now, it displays a warning message when you navigate to Circulation > Curbside pickups, but don't have them configured for the current branch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 43158] New: Add clear button (x) to search input fields
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43158 Bug ID: 43158 Summary: Add clear button (x) to search input fields Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Add a clear/reset button (x icon) on the search input fields that appears when text has been typed, allowing users to quickly clear the search box without manually selecting and deleting the text. Start with the OPAC search input, then extend to the staff interface. This is a common UX pattern in modern web applications (browsers natively support it for type=search inputs, but Koha uses type=text). Implementation options: - Use HTML5 type=search which provides a native clear button in most browsers - Or add a positioned x icon via CSS/JS that clears the input on click The native type=search approach is simpler and more accessible. -- You are receiving this mail because: You are watching all bug changes.

1 11