December 2025 - Koha-bugs - lists.koha-community.org

[Bug 41343] New: Overdue report is too intensive on systems with many overdues
by bugzilla-daemon＠bugs.koha-community.org 27 Jun '26

27 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41343 Bug ID: 41343 Summary: Overdue report is too intensive on systems with many overdues 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 24438] New: index can fail on timeout
by bugzilla-daemon＠bugs.koha-community.org 27 Jun '26

27 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24438 Bug ID: 24438 Summary: index can fail on timeout Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com We have seen occasional timeouts when indexing elasticsearch, these cause the indexing to stop and fail. We should handle the response as the code indicates: 102 sub update_index { 103 my ($self, $biblionums, $records) = @_; 104 105 my $conf = $self->get_elasticsearch_params(); 106 my $elasticsearch = $self->get_elasticsearch(); 107 my $documents = $self->marc_records_to_documents($records); 108 my @body; 109 110 for (my $i=0; $i < scalar @$biblionums; $i++) { 111 my $id = $biblionums->[$i]; 112 my $document = $documents->[$i]; 113 push @body, { 114 index => { 115 _id => $id 116 } 117 }; 118 push @body, $document; 119 } 120 if (@body) { 121 my $response = $elasticsearch->bulk( 122 index => $conf->{index_name}, 123 type => 'data', # is just hard coded in Indexer.pm? 124 body => \@body 125 ); 126 } 127 # TODO: handle response 128 return 1; 129 } -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 28502] New: Changing patron category from child to adult doesn't delete non patron guarantor data.
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28502 Bug ID: 28502 Summary: Changing patron category from child to adult doesn't delete non patron guarantor data. Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: didier.gautheron(a)biblibre.com Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com But guarantor name and relationship fields aren't displayed anymore and librarian can't delete them manually. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 38185] New: DT - replace dom with layout
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38185 Bug ID: 38185 Summary: DT - replace dom with layout Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 36640 https://datatables.net/upgrade/2#dom-property """ dom is still available in DataTables 2 (likely it will be dropped in v3 whenever that happens!), but the default CSS for DataTables has been updated for layout and does not include styling for dom. If you need to continue using dom, you will likely need to add some CSS to position the elements as you need. However, you are strongly encouraged to update to using layout. """ Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36640 [Bug 36640] Upgrade DataTables from 1.13.6 to 2.x -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 67

[Bug 36444] New: Place Holds for Patrons Purchase Suggestion when not using Acquisitions Process
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36444 Bug ID: 36444 Summary: Place Holds for Patrons Purchase Suggestion when not using Acquisitions Process Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com With the passing of the bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27595, holds can now be placed on purchase suggestions, however, this only applies to purchase suggestions that are ordered through Acquisitions. It would be nice if this process could work without using the Acquisitions Module. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 19358] New: Purchase suggestions - enhancements to linking to orders
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19358 Bug ID: 19358 Summary: Purchase suggestions - enhancements to linking to orders Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org 1 - Build a matching tool between purchase suggestions and staged files for Koha using standard fields 1a - Allow for defining fields to match (ISBN -> 020 ) etc. 1b - Add the biblionumber to the request 2 - Build a search tool for suggestions to allow linking multiple suggestions to a staged file 2a - This will be a popup window and allow for multiple suggestions selected to link to the biblio 3 - When an item is received on the linked biblio the receiving process will check for linked suggestions and notify the user(s) using a defined template -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 27190] New: Debug REST API tests
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27190 Bug ID: 27190 Summary: Debug REST API tests Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org It can be tricky to debug REST API tests. You can get a "received 500 when 200 expected", but you don't have the error. There is one manual way to do it: $t->put_ok($url)->status_is(200)->json_is($expected_json)->or( sub { warn $t->tx->res->to_string }); But could we provide a generic way to add a diag in case Test::Mojo fails? -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 40800] New: TransferArrived needlessly triggers alerts in SIP
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40800 Bug ID: 40800 Summary: TransferArrived needlessly triggers alerts in SIP Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org A SIP check-in incorrectly triggers alerts when receiving items in transit at the destination library due to the NotIssued status combined with the TransferArrived message. When an item in transit is checked in at its destination library via SIP clients (sorters, self-service kiosks), the system generates an alert because it finds both: * NotIssued status (item not checked out to a user), therefore a checkin failure * Transfer receipt message Whilst this combination appropriately provides informational messages in the staff client, it's inappropriate for SIP contexts where automated systems don't require transfer receipt notifications and the alert disrupts workflow. The item status transition works correctly (transit → available), but the SIP response incorrectly signals an alert condition, preventing automated systems like sorters from processing transferred items seamlessly. Expected Behaviour SIP check-in of transit items at destination libraries should complete without alerts, allowing automated systems to process transferred items without manual intervention. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 39936] New: Configure blocks per action and per interface in restriction types
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39936 Bug ID: 39936 Summary: Configure blocks per action and per interface in restriction types Change sponsored?: --- 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 23681 We should make patron restriction types more configurable. Within each restriction type, one should be able to choose whether to allow or block any of a list of actions from any of a list of interfaces. Actions to allow or block: - checkout - renewal - hold - ILL request - purchase suggestion Interfaces to allow or block each action via: - intranet - koha OPAC - SIP - API Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23681 [Bug 23681] Make patron restrictions user definable -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 41368] New: Tools/ManageMarcImport_spec.ts is failing
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41368 Bug ID: 41368 Summary: Tools/ManageMarcImport_spec.ts is failing Initiative type: --- Sponsorship --- status: Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Continuous Integration Assignee: tomascohen(a)gmail.com Reporter: lucas(a)bywatersolutions.com To recreate: 1. cypress run --spec t/cypress/integration/Tools/ManageMarcImport_spec.ts 2. It fails -- You are receiving this mail because: You are watching all bug changes.

1 37