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

[Bug 41103] New: Click on data providers platform breaks functionality
by bugzilla-daemon＠bugs.koha-community.org 17 Feb '26

17 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41103 Bug ID: 41103 Summary: Click on data providers platform breaks functionality Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk Created attachment 188441 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=188441&action=e… bug on console to recreate: - add a data provider to harvest sushi data in /cgi-bin/koha/erm/eusage/usage_data_providers - I used Hanser as it seems not to reply with a PR report !!! - add Report types: PR - perform a harvest - then go to /cgi-bin/koha/erm/eusage/usage_data_providers/<provider id> - open developer tools (F12 on Firefox) - click on Platforms - see error in console - any other click won't work in providers nav bar -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 40017] New: Z39.50 search: Allow leader and specific control field positions in Additional fields
by bugzilla-daemon＠bugs.koha-community.org 17 Feb '26

17 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40017 Bug ID: 40017 Summary: Z39.50 search: Allow leader and specific control field positions in Additional fields Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Would be nice to include things like 000p6-7 for position 6 and 7 of leader (field '000') 008p35-37 (pos 35-57, language) of 008 in the prefs for additional fields in Z39.50 search. AdditionalFieldsInZ3950ResultSearch AdditionalFieldsInZ3950ResultAuthSearch -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 36026] New: Need TLS MySQL Connection Without Mutual Authentication
by bugzilla-daemon＠bugs.koha-community.org 17 Feb '26

17 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36026 Bug ID: 36026 Summary: Need TLS MySQL Connection Without Mutual Authentication Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: rschet(a)sandia.gov QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org We’ve successfully connected our Koha site (version 22.11.12.000) to an Azure Database for MySQL flexible server without TLS encryption, but we’ve been unable to connect to the Azure MySQL database with TLS encryption enabled and required. The reason for this appears to be that Koha seems to require mutual TLS, which is not supported by the Azure MySQL database. When connecting to MySQL on Azure, TLS clients use a public SSL CA certificate to allow for encrypted communication, and clients are authenticated at the server by usernames and passwords. But in Koha, the koha-conf.xml configuration file calls for a CA certificate and also for client certificate and client key for client authentication with mutual TLS. This works for a local MySQL database but not for a remote Azure MySQL database because the Azure MySQL database does not provide a way to configure the CA certificate, server public key certificate, and server private key, which must be configured correctly for mutual TLS to work. We need a way to connect to a remote MySQL database with TLS through the use of a CA certificate for encryption and username and password for authentication and without mutual TLS (that is, without the use of certificates and keys for authentication). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 58

[Bug 41327] New: `yarn css:build` generates several warnings
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41327 Bug ID: 41327 Summary: `yarn css:build` generates several warnings Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified 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: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 38426 Since bug 38426. Deprecation Warning [legacy-js-api]: The legacy JS API is deprecated and will be removed in Dart Sass 2.0.0. Deprecation Warning [import]: Sass @import rules are deprecated and will be removed in Dart Sass 3.0.0. Deprecation Warning [color-functions]: saturate() is deprecated. Suggestions: Deprecation Warning [color-functions]: desaturate() is deprecated. Suggestions: Deprecation Warning [color-functions]: lighten() is deprecated. Suggestions: Deprecation Warning [color-functions]: darken() is deprecated. Suggestions: Deprecation Warning [color-functions]: red() is deprecated. Suggestion: Deprecation Warning [color-functions]: adjust-hue() is deprecated. Suggestion: Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38426 [Bug 38426] Node.js v18 EOL around 25.05 release time -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 23355] New: Till Cashup Routine
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23355 Bug ID: 23355 Summary: Till Cashup Routine Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With the addition of cash registers in bug 23321 it would be helpful to have a workflow to ease the 'cashup' process. (i.e. matching up cash register contents at the end of the day with the sum of the transactions having taken place.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 199

[Bug 41592] New: Add an enhanced workflow for refunds against anonymous transactions
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41592 Bug ID: 41592 Summary: Add an enhanced workflow for refunds against anonymous transactions Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Depends on: 24082 Add the ability to search and refund transactions from any register when using anonymous_refund permission, allowing staff to process refunds at a different register than where the original payment was made. Currently, the POS register page (pos/register.pl) only displays transactions for the current register. This creates a workflow problem when a patron: 1. Makes a payment at Register A 2. Returns to Register B with their receipt requesting a refund 3. Staff at Register B cannot find the original transaction on their register page 4. Staff must navigate to patron account page to locate and process the refund This is particularly problematic for anonymous transactions where there may be no patron account to search. PROPOSED SOLUTION ----------------- Add a new "Search transactions" or "Process refund" feature accessible from the POS interface that allows staff with anonymous_refund permission to: 1. Search across all registers (or all registers in current branch) by: - Receipt ID / Credit number - Transaction ID / Accountline ID - Item barcode / Product code - Date range 2. Display transaction details including: - Original payment amount - Original register where payment was made - Payment type (CASH, card, etc.) - Items/services purchased - Whether transaction has already been refunded 3. Process refund at current register: - Clearly indicate: "Original payment at Register A, refund from Register B" - Create REFUND credit on the original transaction - Create PAYOUT debit at the CURRENT register (cash leaving current till) - Maintain proper accounting: Register A shows +£10, Register B shows -£10 BENEFITS -------- - Improved customer service (refund at any register) - Better support for anonymous transactions - Maintains accurate per-register accounting - Reduces staff confusion and navigation complexity Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24082 [Bug 24082] Add a 'refund' option to anonymous payments -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 24364] New: Display item holding library in opac issues
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24364 Bug ID: 24364 Summary: Display item holding library in opac issues Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Be able to display the item's holding library in OPAC issues. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 35903] New: In cataloguing authority plugin using autocomplete must set operator exact
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35903 Bug ID: 35903 Summary: In cataloguing authority plugin using autocomplete must set operator exact Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org When cataloguing and using authority plugin, there is auto-completion on inputs and default operator is "contains". When using auto-completion and selecting a result it would be logical to set operator "exact" and submit form. So the usually unique result appears. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 40888] New: and/or/not drop-downs are missing in the Advanced Search form
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40888 Bug ID: 40888 Summary: and/or/not drop-downs are missing in the Advanced Search form Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Created attachment 186984 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=186984&action=e… Advanced search missing and/or drop-downs In the Advanced Search form, if "More options" is selected, each search field should have a drop-down to select between "and", "or", and "not" for that field. However, in 25.05 and main, that drop-down only appears in the first line. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 41158] New: Field 001 replaced when importing records while using autoControlNumber system preference
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41158 Bug ID: 41158 Summary: Field 001 replaced when importing records while using autoControlNumber system preference Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Field 001 is replaced with records local biblionumber when importing records while using autoControlNumber system preference. This happens when using Z39.50 search/import and importing staged records. The manual tells about the system preference like this: "If set to ‘generated as biblionumber’, the control number will be filled with the biblionumber once the record is saved. This will not affect existing records that already have a value in 001. The existing value will be preserved." Replacing the 001 is not right because 001 should correspond to the value stored in field 003. The value in the field 001 is given by the cataloging agency marked in 003. Second problem is that if the 001 is replaced and the record has child records / component records, the connection between the host record and component record is lost. ShowComponentRecords system preference enables the linking component parts. >From the manual: "Components to be displayed are found using the host record’s control number (001) in the child record’s 773$w subfield" How to reproduce the problem with staging: 1. Activate autoControlNumber system preference 2. Find or create a bibliographic record which field 001 is not the records biblionumber. 3. Export the record using the Save button at the Normal view 4. Go to Cataloging -> Stage record for import -> Find the file you just saved 5. Stage the file with a rule to find matches (for example ISBN). If you do not have record matching rules, please make one in Administration -> Record matching rules. Choose to replace the record if match is found. 6. View the batch and check from the Diff column's link that 001 looks the same at this point. 7. Import the batch into the catalog. 8. Go to the record you just updated (or replaced) and click the MARC preview 9. Notice that the 001 field is replaced with records biblionumber How to reproduce by using Z39.50 (this is not a straight forward replacing like it seems to be in staging): 1. Activate autoControlNumber system preference 2. Find or create a bibliographic record which field 001 is not the records biblionumber. 3. Choose under the Edit button "Replace record via Z39.50/SRU" 4. Search for the title from a database that has the same title and choose to import it 5. You will be transferd to the record's editing page 6. Notice that field 001 is empty 7. If the cataloger does not notice the empty field, it will be filled with biblionumber upon saving the record. You can also try both ways while the autoControlNumber is not activated to notice the difference. If the autoControlNumber system preference is deactivated, the 001 stays the same in staging and in Z39.50 the 001 field is not emptied. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4