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

[Bug 42647] New: Search by patron attribute using "starts with" fails if attribute value has a space
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42647 Bug ID: 42647 Summary: Search by patron attribute using "starts with" fails if attribute value has a space Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The patron search by attribute fails if the attribute value contains a space. This is specific to a "Starts with" search which is the default in patron searches. If you switch to "contains" the patron attribute search works correctly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 43042] 500 error when receiving an order in acquisitions
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43042 --- Comment #1 from Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> --- git bisect blames Bug 41950 and when I revert that patchset, no 500 error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 2505] Omnibus: Enable Perl warnings in all modules and scripts
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2505 Bug 2505 depends on bug 35423, which changed state. Bug 35423 Summary: AuthoritiesMarc: Warnings substr outside of string and Use of uninitialized value $type in string eq https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35423 What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42565] New: GetIssuingCharges returns undef when rentalcharge is NULL
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42565 Bug ID: 42565 Summary: GetIssuingCharges returns undef when rentalcharge is NULL Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com GetIssuingCharges initializes $charge = 0 but then overwrites it with the raw value from itemtypes.rentalcharge. When no rental charge is configured (NULL in the database, which is the default), the function returns undef instead of 0. This causes 'Use of uninitialized value' warnings in every caller that does $charge > 0, notably during automatic renewals (cron), SIP checkout/renew, and the OPAC user page. The fix is trivial: normalize NULL to 0 at the assignment point in GetIssuingCharges. All callers already treat the return as numeric and only act on positive values, so this is safe. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 43048] Prevent users from completely removing fields from cataloging frameworks that break Koha
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43048 Phil Ringnalda <phil(a)chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |phil(a)chetcolibrary.org See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42948 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43041] Uncaught exceptions and DBI errors are not timestamped in plack-error.log
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43041 Kyle M Hall (khall) <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle(a)bywatersolutions.com, | |nick(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43041] Uncaught exceptions and DBI errors are not timestamped in plack-error.log
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

1 0

[Bug 43041] Uncaught exceptions and DBI errors are not timestamped in plack-error.log
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43041 --- Comment #4 from Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> --- Created attachment 201863 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201863&action=e… Bug 43041: Uncaught exceptions and DBI errors are not timestamped in plack-error.log Bug 16357 added timestamps to Plack warnings by sending them through Log4perl with the LogWarn middleware. Only warnings take that path. Uncaught exceptions, DBI errors, and anything a script prints to STDERR ( technically nothering does that, but reports/catalogue_stats.pl has some debug code that could in theory ) are written to the psgi.errors stream, so they end up in plack-error.log with no timestamp. This makes it hard to tell when an error happened, or to find all the errors for a given day. This patch adds a tied psgi.errors filehandle that sends those writes through Log4perl, so they are logged with a timestamp in plack-<interface>-error.log alongside the warnings. Test Plan: 1) Add a line that dies to the top of a staff script such as mainpage.pl: die "Bug XXXXX test"; 2) Restart plack 3) Load the staff home page 4) Note the exception is written to plack-error.log with no timestamp 6) Apply this patch 7) Restart plack again 8) Reload the staff home page 9) Note the exception is now written to plack-intranet-error.log with a timestamp, and no longer written to plack-error.log! 10) Change the die to a warn 11) Retart plack again 12) Reload the staff home page 13) Verify the warns still come through as they did pre-patch Signed-off-by: Martin Renvoize <martin.renvoize(a)openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43041] Uncaught exceptions and DBI errors are not timestamped in plack-error.log
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

1 0

[Bug 43041] Uncaught exceptions and DBI errors are not timestamped in plack-error.log
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43041 --- Comment #5 from Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> --- Created attachment 201864 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201864&action=e… Bug 43041: Make intranet_svc mount catch and log uncaught exceptions For reasons unkown, /intranet_svc doesn't have the HTTPExceptions middleware enabled so an uncaught exception in a service script ends up in plack-error.log Test Plan: 1) Add a line that dies to the top of a service script such as svc/checkouts: die "This is a test"; 2) Restart plack 3) Call the service, e.g. load the checkouts tab for a patron, which calls /cgi-bin/koha/svc/checkouts 4) Note the exception is written to plack-error.log with no timestamp 5) Apply this patch 6) Restart plack again 7) Repeat the call 8) Note the exception is now written to plack-intranet-error.log with a timestamp! Signed-off-by: Martin Renvoize <martin.renvoize(a)openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.

1 0