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

[Bug 40725] New: DBRev 23.12.00.003 should be made more resilient
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '26

30 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40725 Bug ID: 40725 Summary: DBRev 23.12.00.003 should be made more resilient Change sponsored?: --- Product: Koha Version: Main 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org DBRev 23.12.00.003 can causes problems if the table we are checking the FK for does not exist, or has gotten a name change. We can make the DBRev more resilient by checking if the tables exist first. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 37901] New: Pseudonymized_transactions should include ILL requests
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '26

30 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37901 Bug ID: 37901 Summary: Pseudonymized_transactions should include ILL requests Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: andrew.auld(a)ptfs-europe.com, katrin.fischer(a)bsz-bw.de, magnus(a)libriotech.no, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com The pseudonymization process aims to duplicate the transactional circulation data from the statistics table in a way that does not allow borrowers to be identified. The statistics table also includes entries for payments and writeoffs that contain the borrowernumber of the impacted patron. We should also record ILL requests in pseudonymized_transactions when pseudonymization is enabled. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 153

[Bug 35976] New: Enlarge the text boxes for Barcode Width and Height
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '26

30 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35976 Bug ID: 35976 Summary: Enlarge the text boxes for Barcode Width and Height Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org With the introduction of the barcode width and height options ( bug 10762), a user can now add values to adjust these dimensions. It would be very nice if the boxes for the values were bit bigger or adjustable. The boxes only hold 2 digits, but most libraries will be adding 3 digits in this box, such as 0.02 . To see the value, the cursor needs to be placed in the text box and arrowed over to see the contents. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 35704] New: Parent and child itemtype hold limits not enforced as expected
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '26

30 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35704 Bug ID: 35704 Summary: Parent and child itemtype hold limits not enforced as expected Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Similar to bug 30324, the hold limits aren't enforced for parent/child item types. A parent limit doesn't seem to matter at all in this case. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 39398] New: Improve style and layout of staff interface advanced search form
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '26

30 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39398 Bug ID: 39398 Summary: Improve style and layout of staff interface advanced search form Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 38294 Created attachment 179556 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179556&action=e… Screenshot of the proposed updated interface I have a number of style and layout changes I'd like to make to the staff interface's advanced search form. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38294 [Bug 38294] Checkbox/label for search filters incorrectly aligned -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 36669] New: Add ability to charge for bookings
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '26

30 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36669 Bug ID: 36669 Summary: Add ability to charge for bookings Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com Depends on: 29002 One can charge for reservations, we'd like to also add the option for charging for bookings. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29002 [Bug 29002] Add ability to book items ahead of time -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 42234] New: OPAC checkout history page table header contains no text
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '26

30 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42234 Bug ID: 42234 Summary: OPAC checkout history page table header contains no text Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org To recreate: 1. Have a user with checkouts 2. Log into the OPAC and go to "Checkout history". 3. In the checkout history table, the first <th> contains no text. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 42485] New: Elasticsearch dynamic mapping date detection causes indexing failures with ARRAY MARC format
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '26

30 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42485 Bug ID: 42485 Summary: Elasticsearch dynamic mapping date detection causes indexing failures with ARRAY MARC format Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major 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 When ElasticsearchMARCFormat is set to ARRAY, the marc_data_array field is configured with dynamic:true in field_config.yaml. Elasticsearch auto-detects field types based on the first document indexed. If a MARC subfield value looks like a date (e.g. '2024-01-15' in 952$e/booksellerid), ES permanently locks that subfield's mapping to type 'date'. All subsequent records with non-date values in the same subfield fail to index with a document_parsing_exception. This affects any subfield stored in marc_data_array that is not explicitly mapped in Koha's search field configuration â most notably item subfields like 952$e (acquisition source), 952$d (date of acquisition), and 952$w (replacement price date). The same issue applies to numeric detection: if the first value for a subfield looks numeric, ES maps it as 'long', and subsequent text values fail. **Root cause** field_config.yaml configures marc_data_array as: marc_data_array: type: object dynamic: true There is no date_detection or numeric_detection control, so ES uses its default behavior of guessing types from values. **Steps to reproduce** 1. Launch a fresh KTD: $ ktd --search-engine es8 --name broken-es --proxy up -d $ ktd --name broken-es --wait-ready 180 2. Get a shell: $ ktd --name broken-es --shell 3. Set ARRAY format, flush cache, wipe records, reset index: k$ koha-mysql kohadev -e "UPDATE systempreferences SET value='ARRAY' WHERE variable='ElasticsearchMARCFormat';" k$ echo 'flush_all' | nc -q1 memcached 11211 k$ koha-mysql kohadev -e "DELETE FROM biblio_metadata; DELETE FROM items; DELETE FROM biblioitems; DELETE FROM biblio;" k$ koha-shell kohadev -c 'rebuild_elasticsearch.pl -d -r --biblios' 4. Add a record with a date-like value in 952$e (booksellerid): k$ koha-shell kohadev -p -c 'perl -MC4::Biblio -MMARC::Record -MMARC::Field -MKoha::Item -e " my \$r = MARC::Record->new(); \$r->append_fields( MARC::Field->new(q{245}, q{1}, q{0}, a => q{Record one}), MARC::Field->new(q{942}, q{ }, q{ }, c => q{BK}), ); my (\$bn) = C4::Biblio::AddBiblio(\$r, q{}); Koha::Item->new({ biblionumber => \$bn, biblioitemnumber => \$bn, homebranch => q{CPL}, holdingbranch => q{CPL}, itype => q{BK}, booksellerid => q{2024-01-15}, })->store; print qq{Added biblio \$bn\n}; "' 5. Index it (this poisons the mapping): k$ rebuild_elasticsearch.pl --biblios -bn <biblionumber> 6. Verify ES auto-detected 952$e as type 'date': k$ curl -s 'es:9200/koha_kohadev_biblios/_mapping/field/marc_data_array.fields.952.subfields.e' => {"type":"date"} 7. Add a second record with a non-date value in 952$e: k$ koha-shell kohadev -p -c 'perl -MC4::Biblio -MMARC::Record -MMARC::Field -MKoha::Item -e " my \$r = MARC::Record->new(); \$r->append_fields( MARC::Field->new(q{245}, q{1}, q{0}, a => q{Record two}), MARC::Field->new(q{942}, q{ }, q{ }, c => q{BK}), ); my (\$bn) = C4::Biblio::AddBiblio(\$r, q{}); Koha::Item->new({ biblionumber => \$bn, biblioitemnumber => \$bn, homebranch => q{CPL}, holdingbranch => q{CPL}, itype => q{BK}, booksellerid => q{My Vendor Name}, })->store; print qq{Added biblio \$bn\n}; "' 8. Try to index â THIS FAILS: k$ rebuild_elasticsearch.pl --biblios -bn <biblionumber> -v -v -v => Record #N failed to parse field [marc_data_array.fields.952.subfields.e] of type [date]... 'My Vendor Name' (document_parsing_exception) **Proposed fix** Set date_detection: false and numeric_detection: false at the mapping root level in get_elasticsearch_mappings() in Koha::SearchEngine::Elasticsearch. These are index-level mapping parameters (not per-field), so they cannot be set in field_config.yaml on the marc_data_array object definition. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 41992] New: Checkout History remembering Last Page
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '26

30 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41992 Bug ID: 41992 Summary: Checkout History remembering Last Page Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sharon.dugdale(a)cumbria.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com When searching the CHECKOUT HISTORY of an item that has numerous pages, whichever page is the last one looked at on screen, KOHA remembers and the next time the checkout history is looked at on the same or a different item,that last page viewed is the page it opens, not page 1. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 42229] New: Form label used on non-form elements on opac-memberentry.tt pages
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '26

30 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42229 Bug ID: 42229 Summary: Form label used on non-form elements on opac-memberentry.tt pages Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org On opac-memberentry.tt there are some form label's used on elements that are not part of a form. To recreate: 1. Log in into OPAC and go to the "Personal details" page. 2. See elements like: <li> <label>Username:</label> koha </li> You cannot interact with this, so it should not be <label> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20