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

[Bug 38270] New: Add MARCXML options to ElasticsearchMARCFormat
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '26

19 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38270 Bug ID: 38270 Summary: Add MARCXML options to ElasticsearchMARCFormat Change sponsored?: --- 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org As noted on bug 27365, Elasticsearch search results don't get fetched correctly if a MARCXML record cannot be serialized in the compact ISO MARC 2709 format. One reason it might not be able to be serialized is due to 1 MARC field containing more than 9999 bytes or a whole record containing more than 99999 bytes. The change to be provided here will store MARCXML instead of ISO MARC 2709. -- During development, it may be found that a compressed form of MARCXML is preferred to an uncompressed form to be more comparable with the currently stored ISO MARC. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 39107] New: kohastructure.sql doesn't load on new MySQL versions
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '26

19 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39107 Bug ID: 39107 Summary: kohastructure.sql doesn't load on new MySQL versions Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I just read the MySQL 9.2 GA announcement so felt tempted to try it with `KTD`. It doesn't work, so I also tested other versions: # TL;DR * 8.0 -> OK * 8.4 (LTS) -> FAIL * 9.0 -> FAIL * 9.1 -> FAIL * 9.2 -> FAIL Based on the error, it should be solved easily by adding a UNIQUE constraint. To reproduce: 1. Run: $ DB_IMAGE=mysql:9.2 ktd up => FAIL: "DBD::mysql::st execute failed: Failed to add the foreign key constraint. Missing unique key for constraint 'illrequests_safk' in the referenced table 'authorised_values' at /usr/share/perl5/DBIx/RunSQL.pm line 290, <$args{...}> line 1. Something went wrong loading file /kohadevbox/koha/installer/data/mysql/kohastructure.sql ([SQL ERROR]: CREATE TABLE `" 2. Run: $ DB_IMAGE=mysql:9.1 ktd up => FAIL: "DBD::mysql::st execute failed: Failed to add the foreign key constraint. Missing unique key for constraint 'illrequests_safk' in the referenced table 'authorised_values' at /usr/share/perl5/DBIx/RunSQL.pm line 290, <$args{...}> line 1. Something went wrong loading file /kohadevbox/koha/installer/data/mysql/kohastructure.sql ([SQL ERROR]: CREATE TABLE `" 3. Run: $ DB_IMAGE=mysql:9.0 ktd up => FAIL: "DBD::mysql::st execute failed: Failed to add the foreign key constraint. Missing unique key for constraint 'illrequests_safk' in the referenced table 'authorised_values' at /usr/share/perl5/DBIx/RunSQL.pm line 290, <$args{...}> line 1. Something went wrong loading file /kohadevbox/koha/installer/data/mysql/kohastructure.sql ([SQL ERROR]: CREATE TABLE `" 4. Run: $ DB_IMAGE=mysql:8.4 ktd up => FAIL: "DBD::mysql::st execute failed: Failed to add the foreign key constraint. Missing unique key for constraint 'illrequests_safk' in the referenced table 'authorised_values' at /usr/share/perl5/DBIx/RunSQL.pm line 290, <$args{...}> line 1. Something went wrong loading file /kohadevbox/koha/installer/data/mysql/kohastructure.sql ([SQL ERROR]: CREATE TABLE `" 5. Run: $ DB_IMAGE=mysql:8.0 ktd up => SUCCESS: It starts correctly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 34907] New: Load datatables on CMS pages
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34907 Bug ID: 34907 Summary: Load datatables on CMS pages Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be nice we loaded/could optionally load datatables on custom pages for table consistency. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 33364] New: Stop Holds to Pull report showing items that have been allocated to a recall
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33364 Bug ID: 33364 Summary: Stop Holds to Pull report showing items that have been allocated to a recall Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The Holds to Pull report shows an item with a hold if the item is available on the shelf, ready to pull and allocate to the hold. The Holds to Pull should NOT show an item with a hold if that item has already been allocated to a recall (i.e. the recalled item is awaiting pickup and or in transit for a patron). To reproduce: 1. Enable UseRecalls and set the recalls-related circulation rules 2. Check out an item to Patron A 3. Place a hold on the item for Patron B 4. Log into the OPAC as Patron C and search for the item. Place a recall on the item. 5. Go back to the staff interface. Go to Circulation -> Holds to pull 6. Confirm the item shows in the Holds to pull table, with the hold for Patron B 7. Check in the item and confirm the recall as waiting 8. Go back to the Holds to pull page. You could manually regenerate the page but running the cronjob in the terminal misc/cronjobs/holds/build_holds_queue.pl 9. Notice that even though the item is allocated for a recall, the hold is showing. It should not be showing in this page. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 34828] New: Add Koha::MetadataExtractor class
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34828 Bug ID: 34828 Summary: Add Koha::MetadataExtractor class 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: tomascohen(a)gmail.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 43

[Bug 39301] New: pseudonymize_statistics.pl script generates too many background jobs
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39301 Bug ID: 39301 Summary: pseudonymize_statistics.pl script generates too many background jobs Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz The script works, but in a large system it generates a background job per statistic, this can choke the workers and slow system processing. As this is intended as a one-time maintenance script I think we can remove the background-ing and pseudonymize the statistics directly -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 37940] New: [OMNIBUS] All modification logged via action logs should include original to create JSON diff
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37940 Bug ID: 37940 Summary: [OMNIBUS] All modification logged via action logs should include original to create JSON diff 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Now that we can store action logs as a JSON diff of changes, we should implement this for all action logs where we can ( creation and modification ). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 36369] New: Make APIClient be more useful
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36369 Bug ID: 36369 Summary: Make APIClient be more useful Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 I file this report for discussion. In my opinion, there's too much duplicated code on the API client libraries. And the APIClient "class" is just a shortcut to avoid instantiating the module-specific API clients: ```javascript import ERMAPIClient from "./erm-api-client"; ... export const APIClient = { erm: new ERMAPIClient(), ``` Then used everywhere like this: ```javascript import { APIClient } from "../../fetch/api-client.js" ... const client = APIClient.erm await client.agreements.count().then( ``` IMHO, we need a real APIClient class that would implement generic methods like: ```javascript create: params => this.post({ endpoint: params.endpoint ? params.endpoint : "/", body: params.resource, headers: params.headers }), ... getAll: params => this.get({ endpoint: params.endpoint ? params.endpoint : "/", params.query, headers: params.headers, }), ... count: params => this.count({ endpoint: params.endpoint ? params.endpoint : "/", "?" + new URLSearchParams({ _page: 1, _per_page: 1, ...(params.query && { q: JSON.stringify(params.query) }), }), }), ``` and the API Client classes (like ERMAPIClient) should inherit from it, somehow. For doing so, we will face another design roadblock: While I uderstand that ERMAPIClient is a single place to have all the ERM module-needed API actions, it still feels weird from an OOP perspective how things are organized. I feel like we should have individual classes, like: ```javascript export RecordSourcesAPIClient extends APIClient ``` and then have a new type of class along this lines: ```javascript import CitiesAPIClient from "./cities-api-client"; import RecordSourcesAPIClient from "./record-sources-api-client"; ... export const AdminAPIClient = { cities: new CitiesAPIClient(), record_sources: new RecordSourcesAPIClient(), ... }; ``` this way, we will avoid repeating ourselves (less bugs!) and the code is (I expect) more reusable. I also think the `embed` handling should just be a list for the different methods, like: embed: [ 'patron', 'patron.category' ] and generically handled by APIClient. No need to build the headers manually everywhere. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 36046] New: Choose staff interface homepage default action
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36046 Bug ID: 36046 Summary: Choose staff interface homepage default action Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: mirjam.vantieghem(a)etf.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently the default action for the top search box on the staff interface homepage is "Check out". This makes sense for library staff working at the circulation desk. However, for libraries using a self-checkout module, that might not be the desirable default action. We would prefer to have "Search catalog" as default action on the homepage. Would it be possible to have libraries choose the default action on the homepage? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 29285] New: UI tests: Selenium 4 support
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29285 Bug ID: 29285 Summary: UI tests: Selenium 4 support Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org Now v4 is the default when getting the docker image selenium/standalone-firefox . For Selenium 4, the maintainer of our current perl bindings wrote another client: https://metacpan.org/pod/Selenium::Client -- You are receiving this mail because: You are watching all bug changes.

1 15