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

[Bug 40626] New: Edit button in item holdings table on bib details page should offer the same options as on Manage Items
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40626 Bug ID: 40626 Summary: Edit button in item holdings table on bib details page should offer the same options as on Manage Items 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl On the bib details page (/cgi-bin/koha/catalogue/detail.pl) each item has an Edit button in the holdings table. On the Manage Items page (/cgi-bin/koha/cataloguing/additem.pl) each item gets an Actions button that allows the choice of Edit, Duplicate, Print label, Delete, and OPAC view. If you enable LocalCoverImages, the bib details Edit button gets an added side-option allowing selection of Upload Image with 2 clicks (Edit still only takes 1 click). One cannot add an item-level cover from the manage items page. It would be preferable if these two buttons were identical, with each being the sort of two-part button we see on bib-detail when LocalCoverImages is enabled. The button should select Edit when clicked normally, but also allow a click for additional options Duplicate, Print label, Delete, and OPAC view. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 43543] New: Document ChargeFinesOnClosedDays system preference -
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43543 Bug ID: 43543 Summary: Document ChargeFinesOnClosedDays system preference - Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: charles-antoine.frechette(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

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

18 Sep '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 15

[Bug 43108] New: Add a REST API endpoint for a biblio's booking availability over a date range
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43108 Bug ID: 43108 Summary: Add a REST API endpoint for a biblio's booking availability over a date range Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Booking availability (which of a record's bookable items can be booked on which dates, given the lead/trail circulation rules, existing bookings, current checkouts, and the pickup library's closed days) is computed server-side as the single source of truth and exposed over REST. One implementation backs both display and enforcement so they cannot drift; the server returns a compact per-date map rather than making each consumer fetch and process all of a record's bookings and checkouts; and any consumer, whether the Vue booking modal (Bug 41129), another UI, or a third-party integration building its own booking flow, can query it without re-implementing the rules. GET /biblios/{biblio_id}/booking_availability ?from_date=YYYY-MM-DD&to_date=YYYY-MM-DD (required, inclusive, <= 366 days) [&pickup_library_id=...] [&patron_id=...] [&item_type_id=...] [&item_id=...] [&excluded_booking_id=...] (rule/context + edit-exclude) It returns the bookable item ids and a sparse per-(date, item) map. Each cell is an availability result: { "item_ids": [101, 102], "availability": { "2026-08-10": { "101": { "blockers": { "booking": 1 }, "confirms": {}, "warnings": {} }, "102": { "blockers": { "lead": 1 }, "confirms": {}, "warnings": { "holiday": 1 } } } } } - blockers prevent a new booking (booking, checkout, lead, trail); an item with no blockers on a date is bookable, so its available dates are the complement. - warnings are advisory display context only (holiday, lead_floor, lead_theoretical). - confirms is always empty for bookings but present so each cell is a complete availability result. The response shape follows the availability-class pattern currently being established: Bug 41728 (Koha::Result::Availability, to_hashref, where each cell is that shape); Bug 42386 (Koha::{Patron,Item,Biblio}::Availability::Hold, which sets the namespace and snake_case reasons; the class here is Koha::Biblio::Availability::Booking); Bug 42385 and Bug 42387. To stay more or less independent of that series, the class returns a plain hashref rather than subclassing the not-yet-merged Koha::Result::Availability; the shape is compatible, so switching to the real object later is a drop-in change. Booking and checkout day boundaries are attributed to the library timezone (consistent with Bug 42868), matching how bookings are stored and enforced. When item_id names a single item, its own effective item type governs the lead/trail rules (the type enforcement will use), overriding any item_type_id passed alongside it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 43247] New: Transfer reason doesn't show in Checked-in items table for float limit transfers
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43247 Bug ID: 43247 Summary: Transfer reason doesn't show in Checked-in items table for float limit transfers Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 28530 Target Milestone: --- When an item is checked in and is sent to transfer due to the new library float limits feature, the 'Transfer reason' column is blank in the 'Checked-in items' table. The reason shows in logs as 'LibraryFloatLimit', so Koha has the information - it's just not displaying it in that table. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28530 [Bug 28530] Allow configuration of floating limits by item type -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 43516] New: Harden the frontend HttpClient and add a shared API error formatter
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43516 Bug ID: 43516 Summary: Harden the frontend HttpClient and add a shared API error formatter 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 41129 Target Milestone: --- This patch hardens the shared frontend HttpClient (both the plain fetch/http-client.js used by most Vue API clients, and the Vue-composable variant in vue/fetch/http-client.js) against malformed and unreachable API responses, and adds a generic, translated API error formatter. Specifically: - Guard against malformed JSON in responses (a truncated body, a proxy error page, a session-expired redirect) instead of letting the parse error surface as the failure. - Preserve the HTTP status and Koha error_code on thrown errors so callers can branch on them. - Add a per-request config object (config.signal to cancel the underlying fetch via AbortController, config.suppressDefaultErrorDialog for callers that present their own error UI). - Add fetch/api-error.js: a small, translated formatApiError() helper that turns a thrown API error into a user-facing message (401, 403, network-unreachable, and generic fallback cases). This is generic frontend infrastructure with no feature-specific behaviour; it's split out from bug 41129 (booking workflows) because several later patches depend on it and it benefits from independent review. Test plan: 1. Run: yarn cypress run --component --browser electron --spec 't/cypress/component/HttpClient_spec.ts,t/cypress/component/VueHttpClient_spec.ts,t/cypress/component/fetch/api-error_spec.ts' 2. Verify all specs pass. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41129 [Bug 41129] Migrate place_booking.js to a Vue island. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 14604] Offline circulation processor doesn't handle large sets of actions well
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14604 Kyle M Hall (khall) <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14604] Offline circulation processor doesn't handle large sets of actions well
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14604 Kyle M Hall (khall) <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43155] New: POS breaks on modal if change required
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43155 Bug ID: 43155 Summary: POS breaks on modal if change required Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: martin.renvoize(a)openfifth.co.uk Target Milestone: --- This only happens if the patron is owed change. If we enter in an exact amount tendered, everything works. We are seeing a bug with the POS. If I have an amount owed in the POS, like $1.25, and I enter $2.00 tendered, and press confirm, a modal comes up asking to confirm the change owed. If I press yes, nothing happens. If I run console.log("Koha:", Koha); console.log("Koha.prefs:", Koha?.prefs); directly in the browser console on that page, I get: Koha: { ... } Koha.prefs: undefined It looks like Koha.prefs is not being initialized. If I run this in the console on that page: Koha.prefs = Koha.prefs || {}; Koha.prefs.FinePaymentAutoPopup = false; Then I enter the amount tendered over the amount owed, the confirmation comes up, I press yes, and it works. I temporary workaround I've come up with seems to get us by for the moment: //TEMPORARY Workaround for POS bug - 7/22/26 $(function () { Koha = window.Koha || {}; Koha.prefs = Koha.prefs || {}; }); //TEMPORARY Workaround for POS bug - 7/22/26 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 42920] New: Looking up authority records in Advanced editor appends 20 extra spaces
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42920 Bug ID: 42920 Summary: Looking up authority records in Advanced editor appends 20 extra spaces Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: regression Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 21453 Target Milestone: --- The patch for bug 21453 replaced an Advanced editor-specific (in the "[% IF rancor %]" block) "[%- END -%]‡9[% authid | html %]";" which trims whitespace with several lines of "[% ... %]" which do not trim whitespace. The result is that when you look up an authority from the Advanced editor, you get something like ‡aBildungsromans. ‡9220 with twenty extra spaces before the ‡9. While we could restore trimming the whitespace, that section of the patch wasn't needed, and has made things incorrect for anyone who dares to use the Advanced editor with UNIMARC (probably nobody, since it doesn't do UNIMARC fixed-field builders): since the Advanced editor is only used for biblio records, not authority records, it *should* be putting the authid in ‡9 for both MARC flavors the way it was before, but now it will put it in ‡3, the right field for auth-to-auth linking but the wrong field for biblio-to-auth linking. So the right fix is just to revert the changes to the [% IF rancor %]" block. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21453 [Bug 21453] blinddetail-biblio-search.pl/.tt use hardcoded subfield values for MARC21 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18