July 2025 - Koha-bugs - lists.koha-community.org

[Bug 23685] New: Exporting report may consume unlimited memory
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23685 Bug ID: 23685 Summary: Exporting report may consume unlimited memory Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul(a)flo.org QA Contact: testopia(a)bugs.koha-community.org In guided_reports.pl, when exporting report results ($phase eq 'Export') all rows of data are fetched and then converted to the desired format. This may consume an unlimited amount of memory; when report results are particularly large, it may consume all available memory, leading to timed-out HTTP requests, crashes, and potentially data loss. (We have experienced Zebra index corruption as a result.) In master, reports/guided_reports.pl supports three export types -- tab-delimited, CSV, or *.ods. In each case, all data are loaded into memory and held there before any output is produced: 891 $sql = get_prepped_report( $sql, \@param_names, \@sql_params ); 892 my ($sth, $q_errors) = execute_query($sql); ... 895 if ($format eq 'tab') { 896 $type = 'application/octet-stream'; 897 $content .= join("\t", header_cell_values($sth)) . "\n"; 898 $content = Encode::decode('UTF-8', $content); 899 while (my $row = $sth->fetchrow_arrayref()) { 900 $content .= join("\t", @$row) . "\n"; 901 } 902 } else { 903 my $delimiter = C4::Context->preference('delimiter') || ','; 904 if ( $format eq 'csv' ) { ... 914 while (my $row = $sth->fetchrow_arrayref()) { 915 if ($csv->combine(@$row)) { 916 $content .= $csv->string() . "\n"; 917 } else { 918 push @$q_errors, { combine => $csv->error_diag() } ; 919 } 920 } 921 } 922 elsif ( $format eq 'ods' ) { ... 932 # Other line in Unicode 933 my $sql_rows = $sth->fetchall_arrayref(); 934 foreach my $sql_row ( @$sql_rows ) { 935 my @content_row; 936 foreach my $sql_cell ( @$sql_row ) { 937 push @content_row, Encode::encode( 'UTF8', $sql_cell ); 938 } 939 push @$ods_content, \@content_row; 940 } 941 942 # Process 943 generate_ods($ods_filepath, $ods_content); 944 945 # Output 946 binmode(STDOUT); 947 open $ods_fh, '<', $ods_filepath; 948 $content .= $_ while <$ods_fh>; 949 unlink $ods_filepath; 950 } The *.ods case is particularly problematic, because before any data is sent back to the user's browser, *three* copies of the full results are sitting in memory simultaneously -- @$sql_row, @$ods_content, and $content. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 78

[Bug 40477] New: ILL: Patron search in Standard backend / form does not respect PatronAutoComplete system preference
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40477 Bug ID: 40477 Summary: ILL: Patron search in Standard backend / form does not respect PatronAutoComplete system preference Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com When you add a new interlibrary loan request using the Standard backend / form the patron search in it does not respect PatronAutoComplete system preference. How to replicate: 1. Enable ILL module with ILLModule system preference 2. Change PatronAutoComplete system preference to "Don't try" 3. Go to the ILL module from the Koha home page 4. Make new ILL request 5. Go to Patron options and start to write to the "Card number, username or surname:" field 6. The field will suggest you patrons -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=40475 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #515 from David Cook <dcook(a)prosentient.com.au> --- Thanks, Pedro. That should be fixed now. Bit surprised this didn't surface in manual testing, since CanBookBeReserved() should've been called when placing a hold for next available item rather than a specific item, which is in the test plan. -- Looking at opac/opac-reserve.pl I think you've helped uncover a different bug. Check out these lines in opac/opac-reserve.pl: my $itemtype = $query->param('itemtype') || undef; my $status = CanBookBeReserved( $borrowernumber, $biblioNum, $branch, { itemtype => $itemtype } )->{status}; I'm looking at main, and it doesn't look like "itemtype" gets passed when doing a "next available" hold. I'll raise a separate bug report for that and CC you. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15326] Add CMS feature
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15326 Aleisha Amohia <aleisha(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |40474 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40474 [Bug 40474] Add option to OPAC Pages that may override OpacPublic setting -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #514 from David Cook <dcook(a)prosentient.com.au> --- Created attachment 184530 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=184530&action=e… Bug 15516: (follow-up) fix count_holds() for CanBookBeReserved() This patch adds search_attrs to count_holds() since these get used with CanBookBeReserved. Test plan: 0. Apply the patch 1. prove t/db_dependent/Koha/Holds.t t/db_dependent/Reserves/HoldGroup.t t/db_dependent/Reserves.t -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '25

23 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10762] Make it possible to adjust the barcode height and width on labels
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '25

22 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10762 --- Comment #62 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Bernardo Gonzalez Kriegel from comment #3) > Currently generated barcodes are images produced using GD::Barcode. > It's not possible to set font size for numbers. This is actually false in multiple ways. Firstly, the barcodes aren't images generated by GD::Barcode. GD::Barcode just produces the numeric barcode sequence. PDF::Reuse::Barcode then creates vector graphics in the PDF. It's pretty neat. Secondly, the barcode numbers are text. You can verify this by going into the PDF generated by the label creator, highlighting the barcode number, copying it, and pasting it elsewhere. That said, the barcode number is generated by PDF::Reuse::Barcode rather than C4::Labels::Label. And the font size is hard-coded in PDF::Reuse::Barcode. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10762] Make it possible to adjust the barcode height and width on labels
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '25

22 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10762 --- Comment #61 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Katrin Fischer from comment #12) > I believe this actually fixes something different than originally reported. > > This makes it possible to pick the size of the barcode, the original was a > bug saying that the font size was not taken into account for the barcode > number shown below the barcode. > > I've filed a new bug and reset this as enh, because it's a nice new feature > now. > > Bug 30819 - Not able to adjust size of barcode numbers I was just thinking that... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10762] Make it possible to adjust the barcode height and width on labels
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '25

22 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10762 --- Comment #60 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Katrin Fischer from comment #56) > Trying to document this for our German version of the release notes we were > wondering what the values actually refer to. It looks like they are scaling > the barcode height and width, but what are the values it scales down and up > from? I get into this issue in bug 40473. Before bug 40473, the way the barcode width is scaled is by using "Barcode width" to scale down the "Label width". That scaled down width is then divided by a calculation of "barcode length" (this calculation is wrong but fixed in bug 40473) to come up with the final x scale factor to apply to the barcode. So if the barcode length is 300 points and the label width is 150 pts and "Barcode width" is .8 or 80%, we multiply 150 pts by .8 to get 120 points of usable label area for our barcode. We then divide 120 by 300 to get a X scale factor of ".4". 300 multiplied by .4 = 120. And that's how the barcode width is scaled. I haven't looked into barcode height. I think that might be different, and I the BARBIB format might not work correctly anymore... I can only manage so many mouthfuls of elephant... -- You are receiving this mail because: You are watching all bug changes.

1 0