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

[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 43121] New: Vue: Don't pattern match on translatable strings
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43121 Bug ID: 43121 Summary: Vue: Don't pattern match on translatable strings Initiative type: --- Sponsorship --- status: 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, matt.blenkinsop(a)openfifth.co.uk, me(a)paulderscheid.xyz Target Milestone: --- I think we've discovered a bad design pattern here, that crept into the Vue work: We sometimes match untranslatable strings on translatable strings, so they won't match in an installation that is not English. Example: koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: { name: "Ordering information", pane: 2 }, koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), I believe there are more occurences for this and we maybe need a coding guideline. In other cases we seem to have both translatable, which probably works, but still seems like a less than ideal pattern. We should be matching on things, that don't change between languages. Note: the problems in the vendor detail Vue is visible as a display bug (sequence of sections) in 26.05. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 30719] New: ILL should provide the ability to create batch requests
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30719 Bug ID: 30719 Summary: ILL should provide the ability to create batch requests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com Some interlibrary loan providers, for example Reprints Desk, allow for ILL requests to be submitted in batches. In the Reprints Desk case, a batch is created with the supplier, then requests are then submitted including the batch ID. Obviously, this workflow may differ according to supplier and these differences should be abstracted away into the supplier backend. For core Koha, we should provide the ability for it to recognise if a given backend can process batch requests. If so, we should provide an interface for creating and manipulating batches within Koha, then submitting a batch to the supplier. It should also be possible to view all batches and the contents of a given batch. The funding institution has defined the following workflow for creating and populating batches: - A encapsulating "batch" is created with a name and a requesting borrower - Requests are added to a batch via two methods: - In bulk: - A form which allows the user to paste in a collection of identifiers, such as DOI / PMID etc. - For each of these identifiers: - The request metadata should be populated via API queries to metadata suppliers, for example, PubMed API or LibKey/Browzine. This behaviour is governed by the presence of appropriate plugins. - (Optional) Once the metadata is populated for an item, we check for item availability via any installed ILL availability plugins - Individually: - A regular ILL request form, requests are added to the batch -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 195

[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

[Bug 43839] New: Add more details on suspending holds
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43839 Bug ID: 43839 Summary: Add more details on suspending holds Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: philip.orr(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de Target Milestone: --- Suspending a hold will allow the checked out item that the hold was placed upon to be renewed as long the hold is still suspended. (And as long as there are no other unsuspended holds) This should be documented in the manual, actually we should also add some more details in general to the suspending holds section to explain what the point of suspending a hold is and what consequences it will have (such as what happens when the checkout is returned before the hold is unsuspended). I think we just need 2-3 more sentences to explain that, shouldn't be much work. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 40610] New: Update OPAC templates to improve east of translation
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40610 Bug ID: 40610 Summary: Update OPAC templates to improve east of translation Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com Looking at [lang]-opac-bootstrap.po I see a lot of instances of repeated %s %s %s indicating opportunities to improve the markup structure to ease the translation process. This patch will tackle a batch of include files: koha-tmpl/intranet-tmpl/prog/en/includes/item-status.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/biblio-title-head.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/biblio-title.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/date-format.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/holds-table.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/masthead.inc -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 41061] New: No longer needed to validate dates manually
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41061 Bug ID: 41061 Summary: No longer needed to validate dates manually 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: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 33703 I've tried to resurrect bug 31149 but finally realised that this code is no longer needed. I think it's coming from the introduction of Masikto by bug 33703. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33703 [Bug 33703] Entering dates should be more flexible accepting different entry formats -- You are receiving this mail because: You are watching all bug changes.

1 14