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

[Bug 22637] New: Add ability to full reindex elasticsearch index from UI
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22637 Bug ID: 22637 Summary: Add ability to full reindex elasticsearch index from UI Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com Target Milestone: --- Button in toolbar on elastic search admin page to initiate full reindex. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 43585] New: Shareable link from item search filling in holding branch despite being blank in initial search
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43585 Bug ID: 43585 Summary: Shareable link from item search filling in holding branch despite being blank in initial search Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: Shane11235(a)protonmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- When copying a shareable link for an item search that has holding branch left blank, the link will populate with holdingbranch_op=%3D however when the link is used to execute the search again Koha will automatically fill in the holding branch field with the users currently logged in branch. Steps to reproduce: -Create an item search specifying an item type and leave home library current library blank. -Run the search. -Copy shareable link and run the search again using the shareable link. Search will return no results -Click "Edit Search" and Home library and Current library will be filled in with the library the current user is logged in under. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 41627] New: Add Koha::CSV::Acquisitions for acquisition exports
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41627 Bug ID: 41627 Summary: Add Koha::CSV::Acquisitions for acquisition exports 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 Depends on: 41619 Blocks: 41621 This bug adds Koha::CSV::Acquisitions to standardize CSV generation for acquisition exports. Files to update: - C4/Acquisition.pm - admin/aqplan.pl Benefits: - Consistent CSV formatting - Proper quote handling - Testable code Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41619 [Bug 41619] Add `Koha::CSV` https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41621 [Bug 41621] Use Koha::CSV everywhere [UMBRELLA] -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 Pedro Amorim (ammopt) <pedro.amorim(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|additional_work_needed | --- Comment #964 from Pedro Amorim (ammopt) <pedro.amorim(a)openfifth.co.uk> --- Thanks. Last 2 follow-ups pushed! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43237] New: 'Expand' column header doesn't appear consistently for collapsed responsive tables in the OPAC
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43237 Bug ID: 43237 Summary: 'Expand' column header doesn't appear consistently for collapsed responsive tables in the OPAC Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 39698 Target Milestone: --- With the responsive tables introduced by Bug 39698, the Course Reserves table has an 'Expand' column header for the column with the '+' button, but others tables I've observed do not. All of them should have the 'Expand' header. Tables without the Expand header include: Holdings Patron's current checkouts Patron's current holds Patron's clubs Patron's checkout history Patron's search history Patron's charges (That list may not be exhaustive as I've only noted the tables that I've found are responsive.) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39698 [Bug 39698] Add option to expand responsive datatable rows by default -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 43582] New: Allow Vue API clients to opt out of the shared HttpClient's generic error banner
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43582 Bug ID: 43582 Summary: Allow Vue API clients to opt out of the shared HttpClient's generic error banner 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- The shared Vue HttpClient (koha-tmpl/intranet-tmpl/prog/js/vue/fetch/http-client.js) unconditionally calls the global setError() helper on any failed API request (see _fetchJSON's .catch(err => { error = err; setError(err); })), showing a generic "Something went wrong: <raw error>" banner regardless of whether the calling component already handles and displays the error itself. This means any Vue component that wants to show its own friendly, translated, context-specific error message ends up showing BOTH the generic banner and its own message for the same failure. This was noticed while testing bug 35837 (Plugin store): a failed plugin install shows both "Something went wrong: Error: SIGNATUREMISMATCH" (global, raw error code) and "This file's signature doesn't match what the store signed -- it may have been altered or corrupted." (local, friendly translated message) at the same time, for the same failure. At least one existing component (RecordSourcesResource.vue) works around this today by supplying an empty local error handler and relying solely on the global banner -- but that means a component can't have both structured/friendly local messaging AND suppress the redundant generic one. This bug proposes adding an opt-out parameter to HttpClient's request methods (get/getAll/post/postForm/etc, threaded through to _fetchJSON) so a caller that's already going to display its own error message can skip the automatic global setError() call for that request, instead of duplicating the message on screen. Test plan: 1. Pick a Vue component that calls a REST endpoint and currently shows its own local error message on failure (e.g. the Plugin store install flow from bug 35837, once landed, triggering a SIGNATUREMISMATCH or similar 403). 2. Confirm today both the generic "Something went wrong: ..." banner and the component's own local error message are shown together. 3. Apply this enhancement's patch and have the component pass the new opt-out flag on its API call. 4. Confirm only the component's own local error message is shown, with no duplicate generic banner. 5. Confirm other, unrelated Vue components that do NOT pass the new flag are unaffected and still show the generic banner as before. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 40990] New: Checkout override allowed without permissions when item has circulation alert
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40990 Bug ID: 40990 Summary: Checkout override allowed without permissions when item has circulation alert Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: maxeinergl(a)gcc.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Koha will allow staff who do not have force_checkout permissions to check out items beyond the maximum number per type allowed if the item has a circulation alert. In this case a warning is offered but staff can click to continue with the checkout. This behavior is different than when items do not have the circulation alert ; in that case the same staff hit a hard block and cannot override the limitation. This may be related to bug 38540. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 38540] New: Checkout override allowed without permissions when item has parts / materials specified
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38540 Bug ID: 38540 Summary: Checkout override allowed without permissions when item has parts / materials specified Change sponsored?: --- 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Koha will allow a user who does not have force_checkout permissions to check out to a user with fines over the NoIssuesCharge amount if the item to be checked out has a value in items.materials has content. To confirm: 1- set AllowFineOverride to Allow, confirm there is a value in NoIssuesCharge 2- have a user with circulate_remaining_permissions but not force_checkout 3- have a patron with fines over the NoIssuesCharge amount 4- have two items: Item A does not have a value in items.materials, Item B does 5- log in as your user, find your patron 6- attempt to check Item A out to your patron, Koha tells you "Cannot check out" and "Patron has a debt" 7- attempt to check out Item B, Koha says "Please confirm checkout," tells you about the debt and the materials note This happens whether or not CircConfirmItemParts is on. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 30894] New: Add ability to select all/clear all and delete selected label batches
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30894 Bug ID: 30894 Summary: Add ability to select all/clear all and delete selected label batches Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When managing label batches (label-manage.pl) it would be handy to be able to select all/clear all label batches. It would also be nice if you could delete all selected batches instead of having to go through your batches and delete them one at a time -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 7386] Label batches cannot be batch deleted
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7386 Marie-Luce Laflamme <marie-luce.laflamme(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marie-luce.laflamme@inlibro | |.com --- Comment #9 from Marie-Luce Laflamme <marie-luce.laflamme(a)inlibro.com> --- It would be a huge help if we could delete multiple batch labels. Someone else as mentioned this improvement in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30894 and adding an option in the cleanup.database script https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31969. -- You are receiving this mail because: You are watching all bug changes.

1 0