July 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 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 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

[Bug 29392] New: Add plugin hooks before merging biblios or authorities
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '26

28 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29392 Bug ID: 29392 Summary: Add plugin hooks before merging biblios or authorities Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org For when we want to modify the final record of a merge operation -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 41358] New: action logs info column should always store JSON
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '26

28 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41358 Bug ID: 41358 Summary: action logs info column should always store JSON Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com In C4/Circulation.pm: # Log the checkout if ( C4::Context->preference('IssueLog') ) { my $info = $item_object->itemnumber; if ( defined($confirmations) || defined($forced) ) { $info = to_json( { issue => $issue->issue_id, branchcode => $issue->branchcode, itemnumber => $item_object->itemnumber, confirmations => $confirmations, forced => $forced }, { pretty => 1, canonical => 1 } ); } logaction( "CIRCULATION", "ISSUE", $patron->borrowernumber, $info, ); } It appears there is a way, if $forced and $confirmations is undef, to store just the itemnumber. If we are going to store JSON it should always be JSON. Storing the itemnumber sometimes and a JSON object other times makes reporting really hard. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58