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

[Bug 43793] New: 26.05.04 backport of bug 42605 is incomplete
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43793 Bug ID: 43793 Summary: 26.05.04 backport of bug 42605 is incomplete Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: mark(a)hofstetter.at QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- This is a follow-up to bug 42605: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42605 The fix released in Koha 26.05.04 only corrects AcqCreateItem. UniqueItemFields is still converted to the numeric value 0/1, so the acquisition receiving dialog remains broken when items are created on receipt. Tested package ============== koha-common 26.05.04-1 Steps to reproduce ================== 1. Set AcqCreateItem to "receiving an order". 2. Set UniqueItemFields to a non-empty value, for example "barcode|stocknumber". 3. Create an order and open it for receipt. 4. Observe that the receiving dialog remains on its loading indicator and the item-entry form is not displayed. Actual result ============= The English template shipped with 26.05.04 contains: Koha.addPrefs({ AcqCreateItem: "[% Koha.Preference('AcqCreateItem') | html %]", UniqueItemFields: [% Koha.Preference('UniqueItemFields') ? 1 : 0 | html %], }); JavaScript therefore receives the number 1 and additem.js fails when it calls: unique_item_fields.split("|") Expected result =============== Both preferences must remain strings: Koha.addPrefs({ AcqCreateItem: "[% Koha.Preference('AcqCreateItem') | html %]", UniqueItemFields: "[% Koha.Preference('UniqueItemFields') || '' | html %]", }); Cause ===== On main, commit 35b58d65c5 from bug 43211 had already corrected UniqueItemFields before bug 42605 commit 757b347bed was applied. The latter therefore only changes AcqCreateItem in its final diff. The 26.05.04 backport appears to include 757b347bed without the relevant change from 35b58d65c5. This makes the stable backport incomplete even though bug 42605 is listed as fixed in 26.05.04. The same incorrect expression is present in the packaged English and de-DE templates. Applying the expected line locally and restarting Plack restores the item-entry form. Please backport the missing UniqueItemFields change to 26.05.x and include it in the next maintenance release. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 42972] New: [25.11.x] Cannot add, edit, or delete MARC overlay rules
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42972 Bug ID: 42972 Summary: [25.11.x] Cannot add, edit, or delete MARC overlay rules Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Works in main, not in 25.11.x. Is this the result of a bad rebase? kohadev-koha@kohadevbox:koha(25.11.x)$ git show 246f299df1ecbc41bdf15dffc01dac25a62fec2b commit 246f299df1ecbc41bdf15dffc01dac25a62fec2b Author: Jan Kissig <bibliothek(a)th-wildau.de> Date: Fri Mar 13 10:17:26 2026 +0000 Bug 35380: Make record sources available in overlay rules This patch enhances the filters in record overlay rules when using the "Source" module. The available filter values are now system defined in Administration -> Record sources and can be extended by own record souces. The former hard coded values (f.e. batchmod, intranet) are added to the database and cannot be deleted. Signed-off-by: David Nind <david(a)davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize(a)openfifth.co.uk> diff --git a/admin/marc-overlay-rules.pl b/admin/marc-overlay-rules.pl index bebaa1d6aca..e472ffdaa41 100755 --- a/admin/marc-overlay-rules.pl +++ b/admin/marc-overlay-rules.pl @@ -26,6 +26,7 @@ use C4::Output qw( output_html_with_http_headers ); use C4::ImportBatch; use Koha::MarcOverlayRules; use Koha::Patron::Categories; +use Koha::RecordSources; my $input = CGI->new; my $op = $input->param('op') || ''; @@ -124,10 +125,14 @@ my $categories = Koha::Patron::Categories->search_with_library_limits( { order_by => ['description'], columns => [ 'categorycode', 'description' ] } )->unblessed; +my @record_sources = + map { $_->{name} } @{ Koha::RecordSources->search->unblessed }; + $template->param( - rules => $rules, - categories => $categories, - messages => $errors + rules => $rules, + categories => $categories, + record_sources => \@record_sources, + messages => $errors ); output_html_with_http_headers $input, $cookie, $template->output; diff --git a/koha-tmpl/intranet-tmpl/prog/en/modules/admin/marc-overlay-rules.tt b/koha-tmpl/intranet-tmpl/prog/en/modules/admin/marc-overlay-rules.tt index ab5bfc3a6dc..5d59b5ba6ed 100644 --- a/koha-tmpl/intranet-tmpl/prog/en/modules/admin/marc-overlay-rules.tt +++ b/koha-tmpl/intranet-tmpl/prog/en/modules/admin/marc-overlay-rules.tt @@ -491,16 +491,21 @@ categories.unshift({ categorycode: "*", description: "*" }); categories = categories.reduce((a, c) => ({ ...a, [c.categorycode]: c.description }), {}); - var module_filter_options = { - source: { - "*": "*", - batchmod: _("Batch record modification"), - intranet: _("Staff interface MARC editor"), - batchimport: _("Staged MARC import"), - z3950: _("Z39.50"), - bulkmarcimport: _("bulkmarcimport.pl"), - import_lexile: _("import_lexile.pl"), - }, + var module_filter_options = { + source: { + '*': '*', + [% FOREACH record_source IN record_sources %] + [% SWITCH record_source %] + [% CASE 'batchmod' %]'[% record_source %]': _("Batch record modification"), + [% CASE 'intranet' %]'[% record_source %]':_("Staff interface MARC editor"), + [% CASE 'batchimport' %]'[% record_source %]': _("Staged MARC import"), + [% CASE 'z3950' %]'[% record_source %]': _("Z39.50"), + [% CASE 'bulkmarkimport' %]'[% record_source %]': _("bulkmarcimport.pl"), + [% CASE 'import_lexile' %]'[% record_source %]': _("import_lexile.pl"), + [% CASE %] '[% record_source %]' : '[% record_source | html %]', + [% END %] + [% END %] + }, categorycode: categories, }; -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 14962] Temp Shelving Location / On Display Module
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 Miranda Nero <mnero(a)oslri.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mnero(a)oslri.net -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 17385] New: Add custom export notices
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17385 Bug ID: 17385 Summary: Add custom export notices Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: bouzid.fergani(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl this patch, add custom export notices using xslt. -- You are receiving this mail because: You are watching all bug changes.

1 448

[Bug 43798] New: Username is not selectable in MARC overlay rules
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43798 Bug ID: 43798 Summary: Username is not selectable in MARC overlay rules Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- When adding or editing MARC overlay rules, selecting Username as the module does not provide a way to select an existing Koha username. Instead, the Filter field requires the username to be entered manually. The wildcard (*) can be used, but there is no option to search for or select a specific user. Adding username autocomplete would allow staff to search for and select an existing username, making it easier to configure user-specific MARC overlay rules while retaining support for manual entry and wildcards. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 33446] New: Revert transit status should have the option to cancel the item transfer as well
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Bug ID: 33446 Summary: Revert transit status should have the option to cancel the item transfer as well 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: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently, when a hold's transit status is reverted, the item remains in-transit until the transfer is completed by a check-in. This makes sense if the item actually is still in-transit, but there are other situations in which this transit status is incorrect and may not be easy to remove. For example, in our system, we have HoldsAutoFill enabled. Occasionally there are exceptions where we don't want a book to be put in transit for a hold, but instead to remain available at its home branch. If the staff member reverts the transit status on the hold, the item still shows as In Transit. But they can't check in the item to complete the transfer without causing the hold to trap again. In this situation, the book shouldn't be showing as In Transit, but there's no simple way to remove that status. It's several extra steps at best to manually cancel the transfer (and most of our staff don't know how to do this, as manual transfers are not a normal part of our workflow, so many items retain an incorrect "In transit" status indefinitely). When a hold's transit status is reverted by the sending librarian because they're not planning on sending the book for whatever reason, it would be great if they could revert the hold transit status and cancel the item transfer all in one step. This could be something as simple as a checkbox option or a drop-down, so that the user can choose between "Revert transit status" versus "Revert transit status and cancel item transfer". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 43817] New: Cancelling a transfer for a hold should have the option to revert transit status
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43817 Bug ID: 43817 Summary: Cancelling a transfer for a hold should have the option to revert transit status Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: dmeininger591(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- -To recreate 1. Put an bib level record on hold 2. Check in one of the items on the record that needs to be transferred 3. Confirm hold and transfer 4. Go to Circ > Transfers to Receive and 'Cancel Transfer' 5. Go to Bib Record and note that item is still in transit Currently, Cancelling a transfer with a hold is a two part process: 1. "Revert the transit" from the bib record "holds" page 2. "Cancel the transfer" from the "Transfers to Receive" page Bug 33446 is the inverse of this bug: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 43836] New: Double-clicking Save in the basic MARC editor creates two bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43836 Bug ID: 43836 Summary: Double-clicking Save in the basic MARC editor creates two bibliographic records 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: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- When a cataloguer clicks "Save" twice in the basic MARC editor while the first request is still being processed, Koha creates two bibliographic records with consecutive biblionumbers. There is no protection against a second submission: the save buttons are never disabled and there is no in-flight flag. koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/addbiblio.tt (25.05.07): 133 $("#saverecord").click(function(e){ e.preventDefault(); onOption(); }); 217 var onOption = function () { return Check(); } 693 function Check(){ ... } 719 document.f.submit(); 900 <form method="post" name="f" id="f" action="/cgi-bin/koha/cataloguing/addbiblio.pl" onsubmit="return Check();" class="marc_editor"> Every click runs Check() again, and Check() calls document.f.submit() again. Each POST carries op=cud-add-biblio with an empty biblionumber, so addbiblio.pl calls AddBiblio() once per request. HOW WE FOUND IT Production site, Koha 25.05.07, a single cataloguer. action_logs holds pairs of CATALOGUING / ADD entries with consecutive biblionumbers, the same borrowernumber, interface 'intranet', and the same timestamp down to the second: 2026-09-04 18:43:37 ADD 33565 2026-09-04 18:43:37 ADD 33566 2026-09-04 19:18:55 ADD 33569 2026-09-04 19:18:55 ADD 33570 One episode produced three records in the same second. In each pair only one record ends up with an item attached and the other stays empty, so the duplicate is easy to spot afterwards, but nothing prevents it from being created. Nine episodes between 2026-08-31 and 2026-09-21, on a site that catalogues around twenty records a month. No file or Z39.50 import was involved (import_batches is empty for the period); all the records were created in the basic MARC editor. REPRODUCED OUTSIDE KOHA A minimal page copying the same pattern (a form with onsubmit="return Check();" where Check() calls document.f.submit()), posting to a server that waits 3 seconds before answering, which is what a slow save looks like: - one click: 1 POST - two clicks 400 ms apart: 2 POSTs, 406 ms apart The delay is what makes it visible. With an instant response the page is already unloading when the second click lands and only one request is sent, which is why this is hard to see on an idle test instance and shows up on a busy production server. Pressing Enter in a field is NOT the cause. form.requestSubmit() fires onsubmit, Check() calls document.f.submit(), and the browser aborts the original submission, so only one POST is sent. We tested this before reporting. TO REPRODUCE 1. Make the response slow: add a sleep to the cud-add-biblio branch of cataloguing/addbiblio.pl, or use a loaded instance. 2. Cataloguing > New record, fill in the mandatory fields. 3. Click Save twice, roughly half a second apart. 4. Two records are created. Check with: SELECT biblionumber, title, timestamp FROM biblio ORDER BY biblionumber DESC LIMIT 5; and look for two CATALOGUING / ADD rows with the same timestamp in action_logs. SUGGESTED FIX Disable the save controls (#saverecord, #saveandview, #saveanditems, #saveandcontinue) and set an in-flight flag the first time one of them is used, along the lines of what bug 41922 proposes for the checkout form. cataloguing/additem.pl and the authority editor look like they have the same gap. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43807] New: BorrowerMandatoryField is not being respected in the API
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43807 Bug ID: 43807 Summary: BorrowerMandatoryField is not being respected in the API 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: matt.blenkinsop(a)openfifth.co.uk QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- When creating a patron via the API, the BorrowerMandatoryField syspref is not being respected -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 43770] New: Advanced Editor in Chrome not showing text-decoration in empty spaces
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43770 Bug ID: 43770 Summary: Advanced Editor in Chrome not showing text-decoration in empty spaces Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jheltibridle(a)rcplib.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- In the 155 update to Chrome, support for text-decoration-skip-spaces was added. This impacts the fields in the advanced cataloging editor that use the class fixed-collapsed. If a field doesn't have one of the options chosen, it no longer shows the underline that makes it easy to tell if it is clickable. This could be fixed by adding text-decoration-skip-spaces:none; to the cateditor stylesheet. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9