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

[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 43205] New: reserves.expirationdate to display in 'hold found' pop-up window
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '26

30 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43205 Bug ID: 43205 Summary: reserves.expirationdate to display in 'hold found' pop-up window Initiative type: --- Sponsorship --- status: 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: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Created attachment 202734 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202734&action=e… screenshot of 'hold found' pop up window in Koha Our staff have suggested it would be useful for reserves.expirationdate to display in the 'hold found' pop-up window alongside other information such as the patron details. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43165] New: Allow future weekly opening-hours schedules to be configured and activated automatically per library
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '26

30 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43165 Bug ID: 43165 Summary: Allow future weekly opening-hours schedules to be configured and activated automatically per library Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: i.tortorella(a)arts.ac.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Koha allows opening hours to be recorded for individual libraries, but changes to these hours must be made manually when a new timetable takes effect. Libraries may have several changes of opening hours during the year, for example term-time hours, vacation hours, reduced holiday hours or temporary extended opening. Each branch may also have its own opening pattern and may change to the new timetable on a different date. Where an installation has several branches, Systems staff currently need to update each library manually when the new hours come into effect. This can require changes to be made in several stages and creates a risk that opening hours are updated late or incorrectly. It would be useful to allow staff to create future opening-hours schedules for individual libraries and specify when each schedule should become active. The functionality could allow staff to: 1. Configure a complete weekly opening-hours pattern for a library. 2. Assign an effective start date to the pattern. 3. Optionally assign an end date or select the schedule that should follow it. 4. Prepare several future schedules in advance. 5. Configure different schedules and effective dates for different branches. 6. View the current and upcoming schedules for each library. 7. Edit or cancel a scheduled change before it becomes active. 8. Have Koha activate the relevant schedule automatically on the specified date. A scheduled pattern should be able to include different opening and closing times for each day of the week, including days when the library is normally closed. Example use case: A multi-branch academic library service has different term-time and vacation opening hours for each library. Staff know the dates of the changes in advance and would like to enter the schedules before the start of the academic year. Koha would then automatically activate the relevant vacation timetable at the end of term and the appropriate term-time timetable when the next term begins. At present, staff must wait until each change takes effect and manually amend the opening hours for every branch. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 42786] New: Unauthenticated user details lost when progressing ILL request without linking it to a patron
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '26

30 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42786 Bug ID: 42786 Summary: Unauthenticated user details lost when progressing ILL request without linking it to a patron Initiative type: --- Sponsorship --- status: 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: aude.charillon(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 When using ILLOpacUnauthenticatedRequest, the correct workflow is for library staff to link the unauthenticated ILL request to a patron record before progressing the request. However, if they forget and go straight to progressing the request, there is no block or warning, and the contact details entered by the user disappear. To replicate: 1. Set ILLmodule system preference to Enable. 2. Set ILLOpacUnauthenticatedRequest system preference to Allow. 3. Go to the OPAC, make sure you are not logged in. Place a new interlibrary loan request ({yourdomain}/cgi-bin/koha/opac-illrequests.pl?op=create) 4. Go to the staff interface > ILL module. 5. View your unauthenticated request. There is a section for "Unauthenticated request details" containing the user details. 6. Progress the request: e.g. click Confirm request, then confirm again on the next screen. 7. You are returned to the request view. There is no "Unauthenticated request details" section any more, even though the request has not been linked to a Koha patron. In my opinion, staff should not be able to progress the request (confirm the request or place the request with partners) until it has been linked to a patron record. Or, at the minimum, the "Unauthenticated request details" should be retained until the request has been linked to a patron record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[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 43201] New: escape_str should cast to string in staff interface
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '26

30 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43201 Bug ID: 43201 Summary: escape_str should cast to string in staff interface Initiative type: --- Sponsorship --- status: 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 43192 discovered that escape_str() only works with a string and not a number. Like the fix there for the OPAC, we should fix this in the staff interface too. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[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