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

[Bug 18948] New: Elasticsearch - Reindexes should use aliases to avoid down time while reindexing
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '26

22 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18948 Bug ID: 18948 Summary: Elasticsearch - Reindexes should use aliases to avoid down time while reindexing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: nick(a)bywatersolutions.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This patchset aims to add the ability to leverage the ES alias feature during a reindex - when doing a full reindex or a deletion the indexer will look for an existing index under the alias - if not found it will create a new one, if found it will index into a new index and point the alias there when done and then delete the old index. -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 43581] New: Replace the legacy plugin management pages with a Vue Installed plugins page
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '26

22 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43581 Bug ID: 43581 Summary: Replace the legacy plugin management pages with a Vue Installed plugins page 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 35837 Target Milestone: --- Bug 35837 added a new "Plugin store" page (Administration > Plugins > Plugin store) for discovering and installing plugins from the community plugin store. That work was deliberately scoped as an *addition* alongside the existing plugin management pages (plugins-home.pl, plugins-enable.pl, plugins-upload.pl, plugins-uninstall.pl) rather than a replacement, so it could be reviewed as a self-contained, low-risk patch with nothing removed. This bug is the follow-up that completes the migration: it replaces those legacy Perl/TT pages with a new "Installed plugins" Vue page, built on an extended version of the REST API bug 35837 introduced. Objectives: * Extend GET /api/v1/plugins (already added by bug 35837, currently just an unfiltered "list everything" used by the Plugin store page's own "already installed" check) with capability filtering and full KohaTable/DataTables serverSide pagination, sorting and free-text search support. * Add PUT /api/v1/plugins/{plugin_class} (enable/disable) and DELETE /api/v1/plugins/{plugin_class} (uninstall), both delegating to the existing Koha::Plugins::Handler. * Add a routed "Installed plugins" Vue page (Administration > Plugins > Installed plugins) listing installed plugins with Configure/Run tool/Run report/Run admin/Enable/Disable/Uninstall actions, the classic "View plugins by class" filter, and a "Check for updates" action comparing installed versions against the plugin store's discovery API (reusing bug 35837's plugin-store-api-client.js). * Remove plugins-home.pl, plugins-enable.pl, plugins-upload.pl and plugins-uninstall.pl, and repoint every link to them (admin-home.tt, the admin left-menu, the Tools/Reports plugin listings, the staff-tool wrapper breadcrumb, Koha::Plugins::Base's go_home()) at the new page. Depends on bug 35837: reuses its REST install/upload endpoints and Koha::Plugins::Install/Store, its plugin-store-api-client.js discovery client, and its Dialog.vue confirmation-dialog-over-component-dialog fix. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 [Bug 35837] Add a fully fledged plugin store to Koha -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 35837] New: It would be useful to understand what plugins are being used in the wild.
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '26

22 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 Bug ID: 35837 Summary: It would be useful to understand what plugins are being used in the wild. Change sponsored?: --- Product: Koha Version: master 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)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org HEA hasn't seen much love of late.. it would be great to send back statistics on plugins used in an installation. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 52

[Bug 43592] New: Google Books API quota error
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '26

22 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43592 Bug ID: 43592 Summary: Google Books API quota error 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: amitddng135(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Requesting Google Books data via [https://www.googleapis.com/books/v1/volumes?q=9781492180746](https://www.go… fails with a quota error (HTTP 429 Too Many Requests) because Google requires an API key for reliable, unthrottled requests. Furthermore, querying raw numbers without the isbn: qualifier fails to restrict results precisely to ISBN matches. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 41946] New: Superlibrarian should be able to set protected status on patron creation
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '26

22 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41946 Bug ID: 41946 Summary: Superlibrarian should be able to set protected status on patron creation Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Since bug 36085, the protected flag in a patron account was removed from the patron creation form, regardless of if the user is a superlibrarian. 1. With a superlibrarian account, go to Patrons > New patron > Choose any category --> Before bug 36085 : In "Library management" section, there is a Protected yes/no field --> After bug 36085 : the Protected option is no longer there. If I create a SIP account, I now have to create the account, then go back an edit it to add the protection. Non-superlibrarians should still not be able to set the flag on creation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 39650] New: Updating the protected flag is not possible when creating a new patron
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '26

22 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39650 Bug ID: 39650 Summary: Updating the protected flag is not possible when creating a new patron Change sponsored?: --- 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: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When creating a new patron, it is not possible to update the protected flag even when logged in as a superlibrarian. It is still possible to update this flag when updating an existing patron. This seams liked to bug 36085. The check to set the authorization flag CanUpdateProtectPatron (witch restrict the update to only superlibrarian) is itself in a check for op 'edit_form', 'cud-save' or 'duplicate'. The flag CanUpdateProtectPatron is not passed to the template when creating a new user as the op is 'add_form' even when logged in as a superlibrarian. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 43588] New: Add the biblio.datecreated to the detail display in Koha
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '26

22 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43588 Bug ID: 43588 Summary: Add the biblio.datecreated to the detail display in Koha Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface 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 Target Milestone: --- Koha stores the biblio.datecreated in the DB which I'm told is a bit different than the date you can get from the 008. We should add the biblio.datecreated to the detail display. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 43593] New: Moving lines in marc modification templates
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '26

22 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43593 Bug ID: 43593 Summary: Moving lines in marc modification templates Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: catherine.micklethwaite(a)nhs.net QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The ability to drag and drop or specify a line number when moving lines around in marc modification templates would be very useful. My largest template has over 300 lines - if I've missed something in the middle, it takes a long time using the arrow buttons to move a line to the correct place one line at a time -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 39337] New: Use SQL field to apply OpacSuppression in OAI-PMH
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '26

22 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39337 Bug ID: 39337 Summary: Use SQL field to apply OpacSuppression in OAI-PMH Change sponsored?: --- 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)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 37713, 38330 This is a follow-up to bug 37713 and bug 38330. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37713 [Bug 37713] OAI-PMH - Honour OpacSuppression syspref https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38330 [Bug 38330] Make bib-level suppression a biblio table field instead of part of a marc tag -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 43

[Bug 16631] New: Show groups/categories of reports to authorized staff
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '26

22 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16631 Bug ID: 16631 Summary: Show groups/categories of reports to authorized staff Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be helpful to have reports that are specific groups/categories to be authorized under the reports permissions in a patron account. Not everyone wants to see everyone else's reports, some are similar but are not. Some are for superlibrarians to test, and are not ready for use. It would be great if we could specify groups and even subgroups in the permissions that the staff could access, or specify all groups. All groups should be the norm for a superlibrarian. Christopher -- You are receiving this mail because: You are watching all bug changes.

1 299