August 2023 - Koha-bugs - lists.koha-community.org

[Bug 27917] New: Make it clear that standing orders cannot create items at point of ordering
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '26

26 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27917 Bug ID: 27917 Summary: Make it clear that standing orders cannot create items at point of ordering Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When creating a basket, one chooses whether one wants to create item records when ordering, when receiving, or when cataloging. If your basket is a standing order basket, then it cannot create items when ordering. Koha will allow you to pick "placing an order" for when to create items for a standing order basket, but then will not create the item. When creating a basket, we should not allow one to choose "placing an order" for "Create items when" if one has checked the Standing Order box. We should also not allow one to select default for "Create items when" when making a standing order basket if the AcqCreateItem syspref is set to "placing an order." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 32968] New: Create granular permissions for ERM
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '26

26 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32968 Bug ID: 32968 Summary: Create granular permissions for ERM Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: pedro.amorim(a)ptfs-europe.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Depends on: 32925 Currently, there is only one top-level permission for ERM on the system. Example: Allow a staff member to create agreements but not delete them. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32925 [Bug 32925] Display loading info when a form is submitted -- You are receiving this mail because: You are watching all bug changes.

1 82

[Bug 30956] New: Make 773 visible in default framework
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '26

26 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30956 Bug ID: 30956 Summary: Make 773 visible in default framework Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org 773 is used for EasyAnalytics and for creating child records in Koha and as such linked to specific functionalities, but by default, it's hidden in the default framework. We should make at least atng, maybe more subfields, visible (these are displayed in the detail pages). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 31415] New: Script to automate converting reserves to recalls
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '26

26 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31415 Bug ID: 31415 Summary: Script to automate converting reserves to recalls 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If a record reaches X number of reserves, the library may convert reserves to recalls to prompt patrons to return them sooner. This can be automated with a script. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 38

[Bug 30803] New: output_error should not assume a 404 status
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30803 Bug ID: 30803 Summary: output_error should not assume a 404 status 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org See comments on bug 30261. > There is a fundamental flaw in output_error: > output_with_http_headers $query, $cookie, $template->output, 'html', > '404 Not Found'; > Although we pass $error, it always outputs a 404. I tried sending a 403, and > it does not work! > > The 404 from output_error is caught by Plack middleware and it will output > the 404 error document. In this case the OPAC 404 error document! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[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