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

[Bug 42404] New: Add a batch cover images upload endpoint
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42404 Bug ID: 42404 Summary: Add a batch cover images upload 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 61

[Bug 39164] New: Add max_statement_time to SQL report quieries
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39164 Bug ID: 39164 Summary: Add max_statement_time to SQL report quieries Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: koha(a)trust-box.at Sometimes an unlucky report can create an issue for the DB server. To avoid that an easy to achieve fix would be to add a configurable timeout via max_statement_time to the query. This way the query would abort automatically if going over the time limit. See: https://mariadb.com/kb/en/aborting-statements/ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 54

[Bug 43086] New: Prefill unauthenticated patron information for new ILL requests if available
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43086 Bug ID: 43086 Summary: Prefill unauthenticated patron information for new ILL requests if available Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: olivia.reynolds(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- If an unauthenticated patron makes multiple ILL requests back-to-back, they have to fill in their patron details every time. Saving and prefilling these details would save time in this case. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 40968] New: 'Edit this search' forgets about 'whole_records' and 'weighted_fields'
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40968 Bug ID: 40968 Summary: 'Edit this search' forgets about 'whole_records' and 'weighted_fields' Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Found it while playing with links on bug 40966. To reproduce: 1. Apply bug 40966 2. Perform an adv search as in that bug. Using the 'More options' tab. 3. Include any of the following options (or both): * Search entire MARC record * Apply field weights to search 4. Notice the facets include 'whole_records=1' and/or 'weighted_fields=1' (this is the bug 40966 patch in action) 5. hover the 'Edit this search' link => SUCCESS: It gets the query parameters passed through 6. Click on the link => FAIL: None is really set, we lost search information. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 43354] New: ILL request table search returns a 500 error
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43354 Bug ID: 43354 Summary: ILL request table search returns a 500 error Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Depends on: 33544 Target Milestone: --- The global Search field above the ILL requests table returns a 500 error after the request detail fields were combined into one display column. Steps to reproduce: 1. Enable the ILLModule system preference. 2. Open a patron record. 3. Click "ILL requests history" in the menu on the left. 4. Enter any text in the Search field above the table. Expected result: The table is filtered without an error. Actual result: Koha displays a 500 Internal Server Error and the table does not refresh. Technical note: The combined Request details column has an empty DataTables data source and no related-object search mapping. Global search therefore generates a query for "me." instead of the ILL request extended attributes. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33544 [Bug 33544] Squash some ILL fields to alleviate request table overflow -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 43344] New: OPAC does not show the On order item status when acquisition details are enabled
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43344 Bug ID: 43344 Summary: OPAC does not show the On order item status when acquisition details are enabled Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 36018 Target Milestone: --- When OPACAcquisitionDetails is enabled, the OPAC checks active acquisition orders for each item. For an item linked to an outstanding order, this check logs the following SQL error: Unknown column 'me.quantity' in 'WHERE' The order count returns no value, so the item is not displayed with the On order status. Steps to reproduce: 1. Set OPACAcquisitionDetails to Show. 2. Set AcqCreateItem to create an item when placing an order. 3. Create a basket and add an order for a bibliographic record, including an item. 4. Close the basket so the order is active and outstanding. 5. Open the bibliographic record in the OPAC. Expected result: The item is displayed with the On order status and no SQL error is logged. Actual result: The On order status is not displayed and the SQL error is logged. Technical note: item-status.inc calls item.orders.filter_by_active.count. item->orders is a many-to-many DBIx::Class resultset whose current source alias is ordernumber. filter_by_active hard-codes me.quantity, so the generated SQL refers to an alias that is not present in this query. This was introduced by the Bug 36018 follow-up that qualified quantity to avoid ambiguity in REST API joins. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36018 [Bug 36018] Improve consistency in Acquisition/Order(s) regarding active/current orders -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 43330] New: C4::Tags fails to compile when TagsExternalDictionary is configured
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43330 Bug ID: 43330 Summary: C4::Tags fails to compile when TagsExternalDictionary is configured Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When the TagsExternalDictionary system preference contains a value, C4::Tags fails to compile with: Undefined subroutine &C4::Tags::check_install called at C4/Tags.pm line 44. This can cause HTTP 500 errors throughout the staff interface on pages which load C4::Tags, including the staff home page, catalog detail pages, and Tools. Observed on Koha 25.11.06. The problem appears to be caused by the order in which check_install is imported in C4/Tags.pm. Currently C4/Tags.pm contains: use Modern::Perl; use base 'Exporter'; use C4::Context; BEGIN { ... my $ext_dict = C4::Context->preference('TagsExternalDictionary'); if ( $ext_dict && !check_install( module => 'Lingua::Ispell' ) ) { warn "Ignoring TagsExternalDictionary, because Lingua::Ispell is not installed."; $ext_dict = q{}; } ... } but Module::Load::Conditional is loaded later: use Module::Load::Conditional qw( check_install ); Because the check occurs inside a BEGIN block, the BEGIN block is executed during compilation before Perl reaches the later `use Module::Load::Conditional` statement. As a result, when TagsExternalDictionary has a non-empty value, Perl attempts to call check_install() before that function has been imported. When TagsExternalDictionary is empty, the problem is hidden because this expression short-circuits: $ext_dict && !check_install(...) so check_install() is never called. To recreate: 1. Set the TagsExternalDictionary system preference to a non-empty value, for example: /usr/bin/ispell 2. Restart Plack if necessary. 3. Visit a staff interface page which loads C4::Tags, such as the staff home page or a bibliographic detail page. OR reproduce directly from the command line: perl -MC4::Tags -e 'print "C4::Tags loaded OK\n"' 4. Observe: Undefined subroutine &C4::Tags::check_install called at C4/Tags.pm line 44. BEGIN failed--compilation aborted at C4/Tags.pm line 53. Compilation failed in require. BEGIN failed--compilation aborted. 5. Clear TagsExternalDictionary and clear/update the system preference cache. 6. Run the same command again. 7. C4::Tags loads successfully. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 43259] New: Add to group does not add to group
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43259 Bug ID: 43259 Summary: Add to group does not add to group Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Steps to reproduce: 1 - Create a basket 2 - Create a group basket. At this step or the process : /cgi-bin/koha/acqui/basketgroup.pl clicking on "Add to group" does not add the basket to the group It is broken since 25.11.00. In 24.11, in basketgroups.tt there was an array named "grouped", to which the row containing the chosen element was added. It was created using : grouped = $("#grouped").DataTable($.extend(true, {}, dataTablesDefaults, { and row was added using grouped.row.add( row ).draw(); On main : $("#grouped").kohaTable(dt_params); row is added the same way : grouped.row.add( row ).draw(); This results in a JS error : "Uncaught TypeError: grouped.row is not a function" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 42172] New: With OPACAuthorIdentifiersAndInformation show whole heading, not only $a
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42172 Bug ID: 42172 Summary: With OPACAuthorIdentifiersAndInformation show whole heading, not only $a Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org With the OPACAuthorIdentifiersAndInformation option enabled, selected information about authors is displayed, provided it present in the author's authority record. However, the author's name is limited to subfield $a, which is insufficient--especially in the case of corporate names containing a subordinate unit in $b or in the case of meeting names. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 43126] New: REST API: add holdability endpoints for biblios, items and patrons
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43126 Bug ID: 43126 Summary: REST API: add holdability endpoints for biblios, items and patrons 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Depends on: 43124 Blocks: 43123 Target Milestone: --- Add new REST endpoints built on Koha::Biblio::Availability::Hold and Koha::Item::Availability::Hold (bug 43124). GET /biblios/{biblio_id}/holdability, a single call biblio level holdability verdict plus an item availability summary, replacing the current CanBookBeReserved plus per-item loop pattern. GET /items/{item_id}/holdability, a per-item holdability verdict. Pickup locations are only included when include_pickup_locations=true is passed. POST /biblios/{biblio_id}/holdability/batch, checks holdability for multiple patrons (club holds) or multiple items in a single call. GET /patrons/{patron_id}/hold_eligibility, patron level blockers (debt, restricted, expired, etc) independent of any specific biblio. This is a thin new controller action over the existing Koha::Patron->can_place_holds method, not new backend logic. Also enhance the existing GET /biblios/{biblio_id}/items endpoint with an optional holdability parameter that embeds a per-item holdability object when true and a patron_id is supplied, alongside pagination. Response bodies for the new holdability endpoints serialise the blockers, confirmations and warnings shape of Koha::Result::Availability rather than a bespoke status enum schema. All existing hold endpoints (POST /holds, PATCH and DELETE /holds/{hold_id}, pickup_locations endpoints, suspension_bulk, cancellation_bulk) are unchanged. Test plan 1. Add OpenAPI definitions for each new endpoint under api/v1/swagger. 2. Add controller tests under t/db_dependent/api/v1 for each endpoint, covering holdable, non-holdable and override-required cases. 3. Confirm GET /biblios/{biblio_id}/holdability for a 100 item biblio completes in well under 1 second and issues a small, roughly constant number of queries. 4. Confirm existing hold endpoints are unaffected. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43123 [Bug 43123] Hold placement workflow: Vue modernisation (epic) https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43124 [Bug 43124] Add Koha::Item::Availability::Hold and Koha::Biblio::Availability::Hold -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17