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

[Bug 42826] New: Reports: Allow transfer/adoption of report ownership
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '26

28 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42826 Bug ID: 42826 Summary: Reports: Allow transfer/adoption of report ownership Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Target Milestone: --- Bug 42667 introduces the edit_all_reports permission, restricting report editing to the report's creator unless the librarian holds that permission. This surfaces a gap: there is currently no mechanism to change the borrowernumber recorded as a report's owner. Two common real-world scenarios are blocked without this: 1. Staff departure. A librarian leaves the organisation. Their reports become ownerless (if the patron record is deleted) or remain locked to a departed account. Other staff with create_reports but not edit_all_reports cannot maintain them. 2. Adoption of ownerless/legacy reports. Reports created before ownership tracking was tightened, or imported via Mana, may have no owner. A librarian who wants to claim such a report and take ongoing responsibility for it has no way to do so without involving a superlibrarian. Proposed behaviour: - On the report edit form and/or via a dedicated action in the saved-reports list, a librarian holding edit_all_reports should be able to reassign the report's owner to any other staff patron, or clear the owner field. - A bulk-transfer option for the staff-departure case: reassign all reports owned by patron X to patron Y. This could live in the patron deletion workflow or in the reports administration area. - A librarian without edit_all_reports should be able to adopt an ownerless report (setting themselves as owner), since this is a tightening of access rather than a loosening. Acceptance criteria: - Single-report ownership transfer, restricted to edit_all_reports holders - Ownerless-report adoption available to any create_reports holder - Bulk transfer (move all reports from patron A to patron B), restricted to edit_all_reports holders -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 37172] New: HoldItem and HoldTitle do not check all the values of "hold_fulfillment_policy" rule
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '26

28 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37172 Bug ID: 37172 Summary: HoldItem and HoldTitle do not check all the values of "hold_fulfillment_policy" rule Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org values "homebranch" and "holdingbranch" are not checked, leading to forbidden holds to be put from the ILS-DI interface. I think the controls on "hold_fulfillment_policy" should be done in "CanItemBeReserved" rather than "CheckReserves". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 41825] New: Holds cannot be cancelled after a checkout on the patron checkout page
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '26

28 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41825 Bug ID: 41825 Summary: Holds cannot be cancelled after a checkout on the patron checkout page 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: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Steps to reproduce: 1- Find two items, A and B, from two different bibliographic records. 2- Place a hold on item A for a patron. 3- Go to the patron Checkout page and check out item B. 4- Click on the Holds tab. 5- Click on the Delete icon to cancel the hold and confirm the cancellation. 6- Go back to the patron Checkout page and open the Holds tab. ---> The hold is not deleted. 7- Check out another item. 8- In the Holds tab, select the hold and click Cancel selected. ---> Nothing happens. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 42218] New: ERM Usage – remove Database table erm_usage_yus ?
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '26

28 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42218 Bug ID: 42218 Summary: ERM Usage – remove Database table erm_usage_yus ? Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk The erm_usage_yus table could be removed completely, as it contains redundant information which already exists in the erm_usage_mus -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 42160] New: automatic_renewals.pl reindexes by itemnumber, should reindex by biblionumber
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '26

28 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42160 Bug ID: 42160 Summary: automatic_renewals.pl reindexes by itemnumber, should reindex by biblionumber Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz automatic_renewals.pl does this: push @item_renewal_ids, $auto_renew->itemnumber; ... my $indexer = Koha::SearchEngine::Indexer->new( { index => $Koha::SearchEngine::BIBLIOS_INDEX } ); $indexer->index_records( \@item_renewal_ids, "specialUpdate", "biblioserver" ); So, it is calling index_records with the itemnumbers to be indexed. Everywhere else similar calls to index_records use biblionumbers. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 41129] New: Migrate place_booking.js to a Vue island.
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '26

28 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41129 Bug ID: 41129 Summary: Migrate place_booking.js to a Vue island. 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 Since the bookings functionality requires a significant amount of reactivity due to many interdependent inputs to achieve a good UX, this bug is intended to deprecate place_booking.js in favor of a Vue island that makes this much easier. The goal here is to have a Vue based component that is used for the Staff Interface as well as the OPAC to avoid duplication and diverging implementations and also makes it easier to keep track of problems that then don't need to be fixed in two places. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 337

[Bug 23849] New: Update the list of sysprefs to share with Hea
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '26

28 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23849 Bug ID: 23849 Summary: Update the list of sysprefs to share with Hea Change sponsored?: --- 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: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org We have a lot of sysprefs that are not recorded in Hea. We lack a process to keep the list up-to-date. We are going to have an updated list for 19.11. For next releases it should be a new post release task (https://wiki.koha-community.org/wiki/Post_major_release_tasks) This bug report could be reused for the next releases. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 85

[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 28 Oct '26

28 Oct '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 42

[Bug 40083] New: misc/devel/install_plugins.pl doesn't run the "install" method of plugins.
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '26

28 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40083 Bug ID: 40083 Summary: misc/devel/install_plugins.pl doesn't run the "install" method of plugins. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz After a couple tests, it seems that misc/devel/install_plugins.pl doesn't actually run the "install" methods of plugins. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 41223] New: SUSHI harvest should respect rate limits
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '26

28 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41223 Bug ID: 41223 Summary: SUSHI harvest should respect rate limits Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: jvinke(a)austinseminary.edu QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk Many SUSHI providers have rate limits that will prevent successful harvest of usage statistics if they are exceeded. If a harvest job results in a "Fatal - Client has made too many requests 1020" response, there is currently no recourse because rerunning the harvest will result in the issue. If there were either a built-in rate limit or a setting that could be applied to specific Data Providers it would resolve this. -- You are receiving this mail because: You are watching all bug changes.

1 16