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

[Bug 41914] New: Add patron category description to account payment notice template
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '26

23 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41914 Bug ID: 41914 Summary: Add patron category description to account payment notice template Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: amitddng135(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Add patron category description to account payment notice template Libraries running a paid membership subscription model require the Patron Category Description (from categories.description) to be displayed in the Account Payment Notice. Currently, in Koha, the Account Payment notice template does not expose the Patron Category Description variable, preventing libraries from printing membership type information (e.g., Corporate, Individual, Premium, Student) in payment receipts/letters. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 41382] New: Un/Select All option for patron messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '26

23 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41382 Bug ID: 41382 Summary: Un/Select All option for patron messaging preferences Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kebliss(a)dmpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com It would be useful if there were un/select all checkboxes above each method of notification in a patron's messaging preferences. That way if someone wanted to switch from all SMS to all email, for example, staff wouldn't have to unselect each individual notice and reselect them again. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 39156] New: Add plugin hooks for batch operations on authority, biblio and items
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '26

23 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39156 Bug ID: 39156 Summary: Add plugin hooks for batch operations on authority, biblio and items Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: shi-yao.wang(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 54

[Bug 43133] New: Standardize use of label vs legend
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '26

23 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43133 Bug ID: 43133 Summary: Standardize use of label vs legend 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- In the OPAC advanced search page, there are currently section titles that use <label> and others that use <legend>. When customizing the OPAC, it gives unequal results. I was wondering if there was an accessibility or semantic reason for this or if it was just the result of different people doing things differently over the years. To recreate : 1) Go to the OPAC advanced search page http://kohadev.mydnsname.org:8080/cgi-bin/koha/opac-search.pl 2) Click More options 3) Open the dev tool inspector 4) Hover over the following elements and note the tag used - "Search for:" = legend - "Limit to any of the following:" = legend - "Location and availability:" = label - "Sort by:" = label - "Publication range" = label - "Language" = label - "Audience" = label - "Content" = label - "Format" = label - "Additional content types..." = label -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 43153] New: Fixed field drop boxes in advanced cataloging editor display badly with recent browser updates
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '26

23 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43153 Bug ID: 43153 Summary: Fixed field drop boxes in advanced cataloging editor display badly with recent browser updates Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: maxeinergl(a)gcc.edu QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Created attachment 202390 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202390&action=e… screenshot demonstrating issue in Edge and Chrome, compared with Firefox With recent updates in Chrome and Edge the fixed field drop boxes in the advanced cataloging editor now display poorly. There is text that overruns the drop-down arrow, giving a garbled look. The manual shows an image of how this used to display (https://koha-community.org/manual/25.11/en/html/cataloging.html#advanced-ed…) and I'm attaching screenshots from recent Chrome and Edge versions that show the problem. The problem is most evident in the material type drop boxes in the 006, 007, and oo8 since this is the one box that always appears, but it is also present on the other codes which turn into a drop box when you click into them. This problem was first observed in April in Edge and was documented in Chrome at that time with an update from 146.0.7680.177 to 147.0.7727.55. It is not currently an issue in Firefox that I have seen. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 34037] New: Item Bundles do not correctly checkin the bundle if the 952$3 has text
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '26

23 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34037 Bug ID: 34037 Summary: Item Bundles do not correctly checkin the bundle if the 952$3 has text Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When using the bundled feature, if the item that is getting checked out has a 952$3, the check-in will not be successful. This main item can not have this field, although this field is helpful for staff to know it is a bundle and has items included. Step 1. Create a bundle of items Step 2. The 'main' item in which will be checked out to the patron - make sure it has a 952$3 with text. Step 3 Check out the 'main' item that has the items attached to it. See the materials specified text appear at checkout. Step 4 Checkin in the 'main' item and the subsequent items. Step 5 See that all items are verified Step 6 Koha will bring the staff member back to the screen to do the check-in. Step 7 Go to the 'main' item and see the bundle is still checked out to the patron. Removing the materials specified from the main item, and the check-in will then be successful and be removed from the patron's account. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 43152] New: Allow patron holds and checkout history to be anonymized on distinct intervals
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '26

23 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43152 Bug ID: 43152 Summary: Allow patron holds and checkout history to be anonymized on distinct intervals Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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 Depends on: 29525 Target Milestone: --- Currently the batch_anonymize cronjob removes both holds history and checkout history on the same interval (set with the --days value in the cron). Users have requested the ability to have distinct intervals for the two, so holds history can be kept longer than checkout history (or vice versa). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29525 [Bug 29525] Privacy settings for patrons should also affect holds history -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 29525] New: Privacy settings for patrons should also affect holds history
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '26

23 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29525 Bug ID: 29525 Summary: Privacy settings for patrons should also affect holds history Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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.m.hall(a)gmail.com Adjust Patron Privacy preferences to include holds history into privacy considerations. If patron privacy setting is set to never, never retain holds history (anonymize it). If privacy is set to keep, keep holds history for the patron forever. If privacy is set to default, keep it until library chooses to anonymize hold history. (add holds history functionality or option to batch_anonymise cronjob) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 93

[Bug 42959] New: Migrate staff interface functionality from CGI controller + Template Toolkit to REST API + Vue.js
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '26

23 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42959 Bug ID: 42959 Summary: Migrate staff interface functionality from CGI controller + Template Toolkit to REST API + Vue.js Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Koha's staff interface has historically used Perl CGI controllers (.pl files) paired with Template Toolkit templates (.tt files) to render pages server-side. The modern architecture — already established in modules such as ERM and Preservation — uses REST API endpoints (Koha::REST::V1::*) paired with Vue.js 3 single-page components rendered client-side. This META bug tracks the incremental migration of existing staff interface functionality to the new pattern. Migration pattern: - From: koha/foo.pl (CGI) + koha-tmpl/intranet-tmpl/prog/en/modules/foo.tt (TT) - To: api/v1/swagger/ + Koha/REST/V1/ (REST API) + Vue.js 3 component under koha-tmpl/intranet-tmpl/prog/js/vue/ Goals: - Consistent, testable REST API surface for all major data operations - Improved UI responsiveness and user experience via client-side rendering - Reduced server-side template complexity - Better separation of concerns between data and presentation layers This is a tracking/collection bug only. Individual migration bugs should be filed separately and blocked against this one. Migrations should include REST API tests (t/db_dependent/api/v1/) and Cypress end-to-end tests. Pages that have complex existing workflows should be scoped carefully — partial migrations (e.g. migrating a modal or a tab before the whole page) are acceptable and encouraged. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 37723] New: Holiday exceptions in a range generate incorrectly
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '26

23 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37723 Bug ID: 37723 Summary: Holiday exceptions in a range generate incorrectly Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I am not sure if I edited incorrectly, or if this is a problem in holiday exception generation. But here's what I see On the calendar 1 - Click September 1 2 - In 'To date' click september 7 3 - Title: First week september 4 - Check: Holidays repeated yearly on a range 5 - Save 6 - Click september 3 7 - To date: click September 4 8 - Title: Except 9 - Generate exceptions on a range 10 - Save 11 - On right of screen - click 'Show past entries' 12 - There are exceptions generated for August 26 - 27 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1