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

[Bug 36091] New: Spelling: Patron card number/cardnumber
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '26

25 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36091 Bug ID: 36091 Summary: Spelling: Patron card number/cardnumber Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Not sure which spelling is correct, but consistency is good. $ grep -rn "Patron cardnumber" * koha-tmpl/intranet-tmpl/prog/en/includes/csv_headers/reports/cash_register_stats.tt:4: "[% t("Manager name") | html %]"[% sep | html %]"[% t("Patron cardnumber") | html %]"[% sep | html %]"[% t("Patron name") | html %]"[% sep | html %]"[% t("Transaction library") | html %]"[% sep | html %]"[% t("Transaction date") | html %]"[% sep | html %]"[% t("Updated") | html %]"[% sep | html %]"[% t("Transaction type") | html %]"[% sep |html %]"[% t("Notes") | html %]"[% sep | html %]"[% t("Amount") | html %]"[% sep | html %]"[% t("Title") | html %]"[% sep | html %]"[% t("Barcode") | html %]"[% sep | html %]"[% t("Item type") | html %]" grep: misc/translator/po/.git/objects/pack/pack-b0a884343922aff65f857e780adda0f2bcc2203f.pack: binary file matches grep: misc/translator/po/.git/objects/pack/tmp_pack_O9fPOy: binary file matches misc/release_notes/release_notes_20_05_00.html:1588:<li><a href="http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24329">[24329]</a> Patron cardnumber change times are lost during upgrade for bug 3820</li> misc/release_notes/release_notes_20_05_00.md:1194:- [[24329]](http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24329) Patron cardnumber change times are lost during upgrade for bug 3820 $ grep -rn "Patron card number" * koha-tmpl/intranet-tmpl/prog/en/modules/reports/cash_register_stats.tt:172: <th>Patron card number</th> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 38528] New: Additional fields are not properly fetched in serial subscription details
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '26

25 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38528 Bug ID: 38528 Summary: Additional fields are not properly fetched in serial subscription details Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Since Bug 35044, if get values are not present in the table additional_field_values, they are not displayed to the user. To reproduce: 1 - Create a subscription 2 - Add an additional value: Name: TEST Authorised value: None Repeatable: Not checked Marc field: 245$a for MARC21, 240$a for UNIMARC MARC field mode: get value from marc record Searchable: Not checked 3 - Go on subscription details -> it is not displayed. 4 - Try and edit the subscription, go to page 2 -> value is not displayed 5 - Save -> value is not displayed -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 35

[Bug 37399] New: Itemtype not displayed on holdings table if noItemTypeImages is disabled
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '26

25 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37399 Bug ID: 37399 Summary: Itemtype not displayed on holdings table if noItemTypeImages is disabled Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If syspref "noItemTypeImages" is disabled, holdings table won't display itemtype column. To reproduce: 1. Enable syspref "noItemTypeImages". 2. Find biblio with items. => Note that itemtype column is displayed on holdings table. 3. Disable syspref "noItemTypeImages". => Itemtype column is no longer displayed on holdings table. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 38766] New: Opening, closing, or deleting and invoice from the Action drop-down can cause internal server error
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '26

25 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38766 Bug ID: 38766 Summary: Opening, closing, or deleting and invoice from the Action drop-down can cause internal server error Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Depends on: 38155, 38765 The links to perform invoice actions from the Action menu on invoices.pl pass the search url, so that the page can redirect back to the search results after performing the action. This url includes the selected search filter values. However, if dates were used to filter the search, the url includes the dates formatted according to the local DateFormat system preference, instead of ISO format. This causes a parsing error when redirecting back. Similar errors were fixed on bug 38765 and bug 38155. Building this patch on top of those patches, to make it easier to confirm that all such errors in this template have been fixed. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38155 [Bug 38155] Can't close invoices using checkboxes from invoices.pl https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38765 [Bug 38765] Internal server error when merging invoices in invoices.pl -- You are receiving this mail because: You are watching all bug changes.

1 19

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

25 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 25 Jul '26

25 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 25 Jul '26

25 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 25 Jul '26

25 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 38477] New: Regression: new overdue fine applied incorrectly when using "Refund Lost Item Charge and Charge New Overdue Fine" option in circ rules
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '26

25 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38477 Bug ID: 38477 Summary: Regression: new overdue fine applied incorrectly when using "Refund Lost Item Charge and Charge New Overdue Fine" option in circ rules Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 30254 Bug 30254 fixed this something like this previously. We're seeing erroneous fines created for patrons who previously returned something on time. In production, this occurs when an item is marked lost while not checked out to a patron. When that item is later found and checked in, Koha finds the most recent checkout and generates an overdue fine using the current date as the return date of the item (even though the item was returned at some point in the past). Set these sysprefs: - FinesMode: Calculate and Charge - WhenLostForgiveFine: Forgive - WhenLostChargeReplacementFee: Charge In circ rules: - Have a rule that charges fines - Set Refund lost item replacement fee to "Refund lost item charge and charge new overdue fine" 1 - Have/create item with replacement price 2 - Check item out to patron 1, due date in past 3 - Run fines.pl 4 - confirm fines on patron 1 5 - mark item lost 6 - confirm replacement cost generated and fine forgiven on patron 1 7 - check item in 8 - confirm replacement cost forgiven and new fine generated on patron 1 9 - check item out to patron 2, due date in future 10 - check item in 11 - mark item lost (no replacement fee generated because item is not checked out) 12 - in database, update date_due for checkout to patron 2, set to a date in the past 13 - check item in 14 - confirm patron 2 now has a fine At step 12 we're pushing the date_due of the old issue into the past to make date_due<curdate(). In production, this comes up when there are days between steps 10 and 13. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30254 [Bug 30254] New overdue fine applied to incorrectly when using "Refund lost item charge and charge new overdue fine" option in circ rules -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

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

25 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