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

[Bug 20266] New: Authentication using Shibboleth - bootstrap
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20266 Bug ID: 20266 Summary: Authentication using Shibboleth - bootstrap Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Bug 12046 stated that CAS authentication is too complex to be displayed in a modal window, therefore authentication is displayed in a separate page when CAS authentication is enabled. However, Shibboleth auth is quite the same as CAS auth in terms of complexity, and yet the modal is still used when Shibboleth authentication is enabled. This doesn't seem like a consistant behavior to me. Shouldn't the modal also be disabled when Shibboleth authentication is enabled? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 40347] New: Koha/Hold.t generates diag
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40347 Bug ID: 40347 Summary: Koha/Hold.t generates diag Change sponsored?: --- 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 They are not warnings but we don't really need them in the output # Filling a hold when pref enabled should trigger a test # Filling a hold when pref disabled should not trigger a test # Updating a hold location when pref disabled should not trigger a test # Updating a hold location when pref enabled should trigger a test # Update with no change to pickup location should not trigger a test -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 41012] New: ILSDI_Services.t failing on U22
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41012 Bug ID: 41012 Summary: ILSDI_Services.t failing on U22 Change sponsored?: --- 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 Koha_Main_U22/2183 18:58:19 koha-1 | # Failed test 'Title hidden in output as expected' 18:58:19 koha-1 | # at t/db_dependent/ILSDI_Services.t line 874. 18:58:19 koha-1 | # got: '1' 18:58:19 koha-1 | # expected: '0' 18:58:19 koha-1 | # Looks like you failed 1 test of 11. 18:58:19 koha-1 | 18:58:19 koha-1 | # Failed test 'GetRecords' 18:58:19 koha-1 | # at t/db_dependent/ILSDI_Services.t line 923. 866 my $cgi = CGI->new; 867 $cgi->param( service => 'GetRecords' ); 868 $cgi->param( id => $item->biblionumber ); 869 870 my $reply = C4::ILSDI::Services::GetRecords($cgi); 871 872 my $opac_marcxml = $reply->{record}->[0]->{marcxml}; 873 my @title_matches = ( $opac_marcxml =~ m/This is an awesome title/g ); 874 is( scalar @title_matches, 0, 'Title hidden in output as expected' ); -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 40174] New: Add a way to cleanly insert data in DB from Cypress tests
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40174 Bug ID: 40174 Summary: Add a way to cleanly insert data in DB from Cypress tests Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement 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 We need a way to insert into the DB the objects generated via mockData -- You are receiving this mail because: You are watching all bug changes.

1 58

[Bug 40344] New: KohaTable_spec.ts is failing
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40344 Bug ID: 40344 Summary: KohaTable_spec.ts is failing Change sponsored?: --- 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 > Cannot read properties of undefined (reading 'description') -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 39315] New: Missing tests for KohaTable search on coded value's description
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39315 Bug ID: 39315 Summary: Missing tests for KohaTable search on coded value's description Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 39011 On bug 39011 we added the ability to search on the coded value description, but the changes have not been covered by tests. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 [Bug 39011] Unable to search the holdings table (except home/holding libraries and barcode) -- You are receiving this mail because: You are watching all bug changes.

1 38

[Bug 39286] New: BackgroundJob.t should mock_config
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39286 Bug ID: 39286 Summary: BackgroundJob.t should mock_config Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 35655 Blocks: 34070 Bug 35655 needed to mock the config, but instead introduced new env variables. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34070 [Bug 34070] background_jobs_worker.pl floods logs when it gets error frames https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35655 [Bug 35655] Make it possible to switch off RabbitMQ without any warns in logs/about page -- You are receiving this mail because: You are watching all bug changes.

1 14

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

05 Mar '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 58

[Bug 39995] New: Koha/Biblio.t can fail on slow servers
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39995 Bug ID: 39995 Summary: Koha/Biblio.t can fail on slow servers Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org 16:35:27 koha_1 | # Failed test 'timestamp is added to the biblio object' 16:35:27 koha_1 | # at t/db_dependent/Koha/Biblio.t line 594. 16:35:27 koha_1 | # got: '2025-05-23T14:32:59+00:00' 16:35:27 koha_1 | # expected: '2025-05-23T14:33:00+00:00' 16:35:27 koha_1 | # Looks like you failed 1 test of 34. 16:35:27 koha_1 | 16:35:27 koha_1 | # Failed test 'to_api() tests' 16:35:27 koha_1 | # at t/db_dependent/Koha/Biblio.t line 608. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 39747] New: Wrong system preference 'DefaultHoldExpirationUnitOfTime' in test suite
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39747 Bug ID: 39747 Summary: Wrong system preference 'DefaultHoldExpirationUnitOfTime' in test suite Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Correct preference is 'DefaultHoldExpirationdateUnitOfTime'. Also no reason for ";" : origin/main:t/db_dependent/Reserves.t: t::lib::Mocks::mock_preference( 'DefaultHoldExpirationUnitOfTime', 'days;' ); -- You are receiving this mail because: You are watching all bug changes.

1 12