June 2024 - Koha-bugs - lists.koha-community.org

[Bug 30261] New: opac/tracklinks.pl renders 404 incorrectly
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30261 Bug ID: 30261 Summary: opac/tracklinks.pl renders 404 incorrectly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org As per https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23329#c87, tracklinks.pl will try to generate an intranet 404 instead of an OPAC 404 if the script is visited without the syspref being activated or if the URL is not a valid one to redirect to. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 25551] New: [OMNIBUS] Some tests are failing randomly
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25551 Bug ID: 25551 Summary: [OMNIBUS] Some tests are failing randomly 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)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Keep this open to group tests that are failing randomly -- You are receiving this mail because: You are watching all bug changes.

1 89

[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

[Bug 33284] New: checkout_renewals table retains checkout history in violation of patron privacy
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33284 Bug ID: 33284 Summary: checkout_renewals table retains checkout history in violation of patron privacy Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 30275 The checkout_renewals table introduced in bug 30275 can retain a link between a patron and an issue_id when the patron's privacy is set to Never. That data should be anonymized. To recreate: - have a patron with their privacy set to Never retain reading history - check an item out to the patron, renew it via the OPAC - confirm your patron's borrowernumber can be found in checkout_renewals.renewer_id and the issue_id for your checkout can be found in checkout_renewals.checkout_id - check your item in - confirm your patron's borrowernumber has been removed from old_issues.borrowernumber - confirm your patron's borrowernumber and the issue_id for your checkout can still be found in checkout_renewals.checkout_id (along with a note that the renewal happened via the OPAC, thereby making it perfectly clear that this was a patron renewing the item they had checked out themselves). Should we not replace checkout_renewals.renewer_id with the anonymous patron's borrowernumber when the item is returned, if the patron is set to not retain reading history? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30275 [Bug 30275] Checkout renewals should be stored in their own table -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 57

[Bug 33455] New: Heading on 'update password' page it too big
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33455 Bug ID: 33455 Summary: Heading on 'update password' page it too big Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The h1 heading on the change password page is too big and should be outside of the legend. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 34118] New: Add Patron's home library as an option on the DefaultHoldPickupLocation preference
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34118 Bug ID: 34118 Summary: Add Patron's home library as an option on the DefaultHoldPickupLocation preference Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Some groups want the option to default the pickup location to the patron's home library when placing holds on the staff client rather than the logged in branch or the item's location. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 36261] New: Calculating OpacHiddenItems is too slow in OPAC search
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36261 Bug ID: 36261 Summary: Calculating OpacHiddenItems is too slow in OPAC search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Calculating items and records hidden by OpacHiddenItems it slow. Too slow. Fortunately, I've come up with an optimization which seems to effectively eliminate the overhead added by OpacHiddenItems. Basically, instead of running 1 query per item, I run 1 query per bib to get all hidden items. It's pretty straightforward, but I'd like to battle-test it a bit more. I'm also writing this optimization for an older version of Koha, and I still have more optimizing I want to do, so I'm not going to post my patch just yet... It's coming though! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 36894] New: Journal article request authors do not show in the requests table
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36894 Bug ID: 36894 Summary: Journal article request authors do not show in the requests table Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: matt.blenkinsop(a)ptfs-europe.com CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com The author field for journal article ILL requests is empty in the ILL table -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 34351] New: ILL list table - access_url column content should be clickable
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34351 Bug ID: 34351 Summary: ILL list table - access_url column content should be clickable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com CC: katrin.fischer(a)bsz-bw.de, magnus(a)libriotech.no, martin.renvoize(a)ptfs-europe.com, nick(a)bywatersolutions.com, pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 25778] New: koha-plack --restart causes PERL5LIB to grow with duplicate entries
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25778 Bug ID: 25778 Summary: koha-plack --restart causes PERL5LIB to grow with duplicate entries Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com Line 395 in koha-lack "PERL5LIB=$PERL5LIB:$KOHA_HOME/installer:$KOHA_HOME/lib/installer" causes PERL5LIB to grow with duplicate entries for /usr/share/koha/installer and /usr/share/koha/lib/installer when running in production. Note that this does *not* happen when running in dev, when using koha-testing-docker for instance. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31