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

[Bug 42578] New: Koha/Hold.t failing on date comparison
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42578 Bug ID: 42578 Summary: Koha/Hold.t failing on date comparison Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 40058 We must use t::lib::Dates::compare to compare dates in test. Koha_Main_D13/218 23:27:19 # Failed test 'Timestamp logged is the current one' 23:27:30 # at t/db_dependent/Koha/Hold.t line 1408. 23:27:35 # '$VAR1 = { 23:27:38 # 'biblionumber' => 3801, 23:34:33 # 'borrowernumber' => 3002, 23:34:36 # 'branchcode' => 'lxMFj7PU', 23:34:39 # 'cancellation_reason' => undef, 23:34:41 # 'cancellationdate' => undef, 23:34:45 # 'deleted_biblionumber' => undef, 23:34:49 # 'desk_id' => undef, 23:34:53 # 'expirationdate' => undef, 23:34:56 # 'found' => undef, 23:34:59 # 'hold_group_id' => undef, 23:35:02 # 'item_group_id' => undef, 23:35:05 # 'item_level_hold' => 1, 23:35:08 # 'itemnumber' => 2658, 23:35:10 # 'itemtype' => undef, 23:35:13 # 'lowestPriority' => 0, 23:35:16 # 'non_priority' => 0, 23:35:32 # 'notificationdate' => undef, 23:35:45 # 'patron_expiration_date' => undef, 23:35:54 # 'priority' => 1, 23:36:01 # 'reminderdate' => undef, 23:36:19 # 'reserve_id' => 357, 23:36:23 # 'reservedate' => '2026-05-08', 23:36:27 # 'reservenotes' => undef, 23:36:30 # 'suspend' => 0, 23:36:33 # 'suspend_until' => undef, 23:36:38 # 'timestamp' => '2026-05-08 23:22:04', 23:36:43 # 'waitingdate' => undef 23:36:53 # }; 23:36:58 # ' 23:36:58 # doesn't match '(?^u:'timestamp' => '2026-05-08 23:22:03')' 23:36:58 # Looks like you failed 1 test of 13. 23:36:58 23:36:58 # Failed test 'item-level holds tests' 23:37:04 # at t/db_dependent/Koha/Hold.t line 1433. 23:37:06 # Looks like you failed 1 test of 6. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40058 [Bug 40058] Move RevertWaitingStatus to Koha::Hold->revert_waiting() -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 39302] New: Checkin disappear from checkin list if transfer modal is triggered
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39302 Bug ID: 39302 Summary: Checkin disappear from checkin list if transfer modal is triggered Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com There is a flaw in the logic of the checkin code: we keep 20 (default value for numReturnedItemsToShow) checkins in the table, but there can be shift in the "counter" logic when the transfer modal is triggered. There are actually several other problems in the logic of this controller but we are going to try and focus on only this one. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 39299] New: cn_browser on 952$o fails to open from item editor
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39299 Bug ID: 39299 Summary: cn_browser on 952$o fails to open from item editor Change sponsored?: --- 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Since bug 30975 if you set the cn_browser plugin for 952$o it fails to open in the item editor. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 39878] New: EDIFACT vendor account records sets default port incorrectly for FTP
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39878 Bug ID: 39878 Summary: EDIFACT vendor account records sets default port incorrectly for FTP Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When creating or editing an EDI (EDIFACT vendor record) if the port is left empty it will be set to port 22. This is fine then the service is SFTP, but if FTP is selected the default to 21. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 39864] New: Cannot save Automatic item modifications by age rules
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39864 Bug ID: 39864 Summary: Cannot save Automatic item modifications by age rules Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 38714 To reproduce: 1. Go to Cataloging > Automatic item modifications by age 2. Click Edit rules 3. Click Add rule 4. Enter some values, such as: age -> 365 age field -> items.dataaccessioned substitution -> items.withdrawn = 1 5. Click Save --> Nothing happens, and the save button remains highlighted Git bisect points to bug 38714 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38714 [Bug 38714] Adjust templates for prettier -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 41707] New: The DIE handler in C4::SIP::Trapper is logging non-SIP errors, causing log flooding.
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41707 Bug ID: 41707 Summary: The DIE handler in C4::SIP::Trapper is logging non-SIP errors, causing log flooding. Initiative type: --- Sponsorship --- status: 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: johanna.raisa(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org The DIE handler should be more restrictive and only log errors where the call stack clearly originates from SIP modules (e.g., C4::SIP::*). The current implementation is not strict enough or may have edge cases. Found this kind of errors from our logs: [2026/01/23 13:42:47] [493898] [ERROR] [undef]@[undef]: commandline was not set during initialization at /usr/share/perl5/Net/Server.pm line 100. C4::SIP::Trapper::__ANON__ /home/koha/Koha/C4/SIP/Trapper.pm (70) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 41329] New: yarn install generates 2 warnings regarding datatables-.net-vue3
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41329 Bug ID: 41329 Summary: yarn install generates 2 warnings regarding datatables-.net-vue3 Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 38426 warning " > datatables.net-vue3(a)2.1.3" has unmet peer dependency "datatables.net(a)^1.13.1". warning " > datatables.net-vue3(a)2.1.3" has unmet peer dependency "jquery(a)^3.6.0". How is that bad? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38426 [Bug 38426] Node.js v18 EOL around 25.05 release time -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 39858] New: Cannot save vendor if it has invoices
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39858 Bug ID: 39858 Summary: Cannot save vendor if it has invoices Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I found while trying to add a contact to a vendor. Not sure if the invoices themselves are relevant. To reproduce: 1. Have a vendor with some invoice 2. Try adding a contact (I added a name and an email) 3. Hit 'Submit' => FAIL: You get a yellow error message about a problem saving. => FAIL: The logs say something like: ``` [2025/05/07 18:08:18] [ERROR] PUT /api/v1/acquisitions/vendors/2: unhandled exception (Koha::Exceptions::Object::PropertyNotFound)<<No property invoices_count for Koha::Acquisition::Bookseller>> ``` -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 40820] New: STOMP errors even when JobsNotificationMethod='polling'
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40820 Bug ID: 40820 Summary: STOMP errors even when JobsNotificationMethod='polling' 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org We added the JobsNotificationMethod preference so people can disable the use of RabbitMQ explicitly and not get the logs flooded with connection errors. But a patch on bug 34070 reintroduced the warn ♪┏(・o・)┛♪ e2e587273c14f092d71046f21266473445b219c5 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 34070] New: background_jobs_worker.pl fills logs when not connecting
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34070 Bug ID: 34070 Summary: background_jobs_worker.pl fills logs when not connecting Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org I noticed my disk was filling up, because worker-output.log was getting several hundred of these per second: [2023/06/20 18:21:24] [WARN] Frame not processed - malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "You must log in usin...") at /usr/share/koha/bin/background_jobs_worker.pl line 116. main::catch {...} /usr/share/koha/bin/background_jobs_worker.pl (119) I think the problem is related to this code: 106 while (1) { 107 if ( $conn ) { 108 my $frame = $conn->receive_frame; 109 if ( !defined $frame ) { 110 # maybe log connection problems 111 next; # will reconnect automatically 112 } 113 114 my $args = try { 115 my $body = $frame->body; 116 decode_json($body); # TODO Should this be from_json? Check utf8 flag. 117 } catch { 118 Koha::Logger->get({ interface => 'worker' })->warn(sprintf "Frame not processed - %s", $_); 119 return; 120 } finally { 121 $conn->ack( { frame => $frame } ); 122 }; 123 124 next unless $args; 125 126 # FIXME This means we need to have create the DB entry before 127 # It could work in a first step, but then we will want to handle job that will be created from the message received 128 my $job = Koha::BackgroundJobs->find($args->{job_id}); There is a problem with the connection, but $conn is still defined, so this code is run. When I Dump $conn after line 107 it looks like this: $VAR1 = bless( { 'bufsize' => 8192, 'logger' => bless( { 'warn' => 1, 'error' => 1, 'fatal' => 1 }, 'Net::Stomp::StupidLogger' ), '_framebuf_changed' => 1, 'port' => '61613', 'connect_delay' => 5, '_pid' => ***, 'hostname' => 'localhost', 'reconnect_attempts' => 0, 'reconnect_on_fork' => 1, 'select' => bless( [ '�', 1, undef, undef, undef, undef, undef, undef, undef, bless( \*Symbol::GEN0, 'IO::Socket::IP' ) ], 'IO::Select' ), 'socket' => $VAR1->{'select'}[9], 'initial_reconnect_attempts' => 1, '_framebuf' => '', 'socket_options' => {}, 'subscriptions' => { 'dest-/queue/koha_***-default' => { 'ack' => 'client', 'destination' => '/queue/koha_***-default', 'prefetch-count' => 1 } } }, 'Net::Stomp' ); If I dump the contents of $body after line 115, I get 'You must log in using CONNECT first'. Not sure why that happens yet, but how we handle it seems to be problematic. We fail to decode it, because it is not JSON. So the "catch" block is run and logs the problem. But then I think the "return" kicks us back to the start of the "while" and we end up logging the same error as fast as we can, which seems to be pretty fast. And we never get to the "ack" on line 121. The comment "will reconnect automatically" seems to be a little optimistic? Moving the "return" from the end of the "catch" block, to the end of the "finally" block slows things down, now the logging only happens about every other second. But there is also a problem because we are assigning the "output" from the try/catch to $args. If we can decode_json the $body, that works as expected. But if we execute the "catch" block, it looks like $args gets assigned the result of Koha::Logger->get, which seems to be 1. So $args is defined on line 124 and we get to Koha::BackgroundJobs->find, but using "1" as a hashref there does not work. I think maybe something like this would work better: my $args; try { my $body = $frame->body; $args = decode_json($body); # TODO Should this be from_json? Check utf8 flag. } catch { Koha::Logger->get({ interface => 'worker' })->warn(sprintf "Frame not processed - %s", $_); } finally { $conn->ack( { frame => $frame } ); return; }; Is the return needed? This is a little above my head, so other solutions are most welcome. And if anyone can tell me why I get 'You must log in using CONNECT first' I would be most grateful. :-) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59