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

[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

[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 8589] Advanced Search for itemtype and location produces some results that are not useful
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8589 Luis Bataller <luis.bataller(a)xercode.es> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |luis.bataller(a)xercode.es --- Comment #9 from Luis Bataller <luis.bataller(a)xercode.es> --- Hi all, This bug captures a limitation of searches in Koha under Elasticsearch: filtering by item-level attributes such as itemtype and location returns records where each criterion is satisfied by a different item, rather than by the same physical item. The same cross-item mismatch affects branch/availability filters. We have implemented a solution against current Koha (26.05) and would like to offer it to the community. This is essentially the approach David Cook anticipated in comment #7: Elasticsearch's nested data structures let you require an "AND" across values within the same nested object. We index each record's items as a nested object on the biblios index (alongside the existing flat 952 fields, which are kept untouched), so that item-level conditions are evaluated on the same item. What the work covers so far: Nested item mapping on the biblios index, populated with per-item fields (home/holding branch, itype, location, ccode, callnumber, barcode, acquisition date, lost/withdrawn/damaged, plus derived flags: availability, in-transit, on-hold, on-request, and home/holding geolocation as geo_point). Same-item filtering for facets, branch/multibranchlimit limits and availability — the fix for this bug. Selecting itemtype + location now returns only records with an item matching both. Advanced-search item operands (barcode, location, call number, acquisition-date range) and the item-type limit routed through the same nested channel when the query is a pure-AND (documented fallback to flat for OR/NOT). Reactive reindexing on transfers, holds and library-geolocation changes, so the derived fields stay in sync. OPAC item hiding and record suppression honoured through the nested channel (OpacHiddenItems, hidelostitems, OpacHiddenItemsHidesRecord), including a plugin hook for custom hiding rules. Optionally, showing only the matching items in staff search results (with recalculated counts), behind a new syspref. Together these cover the case Ray Delahunty raised in comment #8: the keyword area, the tab operands and the bottom limits of Advanced Search working together without "not useful" results, including complex multi-site setups where facet (homebranch) filtering currently still leaks cross-item hits. We would be happy to attach the patch series here. Given the size of the change, before uploading everything, we'd appreciate the maintainers' guidance on how you'd prefer to receive it: as a single dependency chain, split into different staged bugs (mapping, filtering, facets …), or whether an RFC is warranted first. Happy to adapt to whatever makes review easiest. Thanks! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42567] New: Remove C4::Koha::GetNormalizedEAN in favor of MetadataExtractor
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '26

12 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42567 Bug ID: 42567 Summary: Remove C4::Koha::GetNormalizedEAN in favor of MetadataExtractor Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 42566 C4::Koha::GetNormalizedEAN duplicates logic that belongs in the MetadataExtractor pattern (Bug 34828). This bug adds get_normalized_ean to the flavor-specific extractors: - MARC21: 024$a with indicator 1 = 3 - UNIMARC: 073$a Then exposes it as $biblio->normalized_ean and migrates all callers. Callers to migrate: - C4::Search - C4::ShelfBrowser - opac-shelves.pl, opac-user.pl, opac-showreviews.pl - virtualshelves/shelves.pl Depends on Bug 42566. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42566 [Bug 42566] Remove C4::Koha::GetNormalizedUPC in favor of MetadataExtractor -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 42330] New: Use main-container.inc from all the templates
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '26

11 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42330 Bug ID: 42330 Summary: Use main-container.inc from all the templates Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We can now use main-container.inc with a custom aside (see bug 42322). Now we need to use it for all our templates. -- You are receiving this mail because: You are watching all bug changes.

1 53

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

11 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 ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- 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 11 Jul '26

11 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43041 --- Comment #2 from Kyle M Hall (khall) <kyle(a)bywatersolutions.com> --- Created attachment 201819 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201819&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! -- 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 11 Jul '26

11 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43041 --- Comment #1 from Kyle M Hall (khall) <kyle(a)bywatersolutions.com> --- Created attachment 201818 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201818&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 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42999] New: $valid_items flag contamination in reserve/request.pl causes non-holdable items to appear as available after the first holdable item in the loop
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '26

11 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42999 Bug ID: 42999 Summary: $valid_items flag contamination in reserve/request.pl causes non-holdable items to appear as available after the first holdable item in the loop Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- Bug 38412 (commit 1900effc9b) introduced $valid_items as a flag to track whether any item passes all availability conditions. However, the flag is also used as a per-item gate in the same loop without being reset between iterations. Once any item sets $valid_items = 1, all subsequent items — regardless of their individual availability — enter the if ($valid_items) branch and are assigned $item->{available} = 1. Root cause (reserve/request.pl): The commit split what was a single if block into two consecutive, separate blocks: # Line 455 — initialized once, outside the loop my $valid_items = 0; for my $item_object (@items) { ... # Block 1 (line 570): per-item condition check if ( !$item->{cantreserve} && !$exceeded_maxreserves && $can_item_be_reserved eq 'OK' && IsAvailableForItemLevelRequest( $item_object, $patron, undef ) ) { $valid_items = 1; # set but never reset between iterations } # Block 2 (line 583): uses $valid_items as per-item gate — BUG if ($valid_items) { # true for ALL items after the first valid one $num_items_available++; $item->{available} = 1; ... } elsif ( C4::Context->preference('AllowHoldPolicyOverride') ) { ... } else { $item->{available} = 0; # never reached after first valid item } } # Line 661 — post-loop: this use of $valid_items is correct if ( $valid_items == 0 ) { $template->param( none_available_override => 1 ); } The variable serves two conflicting roles: Global accumulator (correct, line 661): "did any item pass all checks?" Per-item gate (incorrect, line 583): "does this item pass all checks?" — but it carries over from previous iterations. Steps to reproduce: Create a biblio with at least two items: one with a holdable item type (e.g. Books) and one with a not-for-loan item type (e.g. Reference, itemtypes.notforloan = 1). The not-for-loan item must have a higher itemnumber than at least one holdable item (i.e., it is processed later in the loop). Open the place-hold staff form: reserve/request.pl?biblionumber=X&borrowernumber=Y Expected: The not-for-loan item shows no radio button / is not selectable for holds. Actual: The not-for-loan item has a radio button and available = 1, despite the Information column correctly showing "Not for loan (Itemtype not for loan)". This is reproducible with AllowHoldPolicyOverride either on or off. Diagnostic trace on a local instance running main (as of 2026-07-06, biblionumber 47160, patron borrowernumber 2): AllowHoldPolicyOverride: NO itemno barcode itype ifl can_reserve cond_passes valid_items available branch_taken --------------------------------------------------------------------------------------------------- 27924 FFL24040002 BK 0 OK YES 0->1 1 if($valid_items) 27926 CPL24040004 BK 0 OK YES 1->1 1 if($valid_items) 27936 CPL24050001 BK 0 OK YES 1->1 1 if($valid_items) 28043 CPL24110003 REF 1 OK NO 1->1 1 if($valid_items) <-- BUG 28046 CPL25030002 BK 0 OK YES 1->1 1 if($valid_items) ... Legend: ifl = itemtype notforloan flag cond_passes = item individually passes all availability conditions valid_items = flag value before->after this iteration <-- BUG = actual result differs from correct result Note: in this test case CanItemBeReserved returns OK for the REF item (depending on circulation rules, it may also return notforloan); either way, IsAvailableForItemLevelRequest returns false due to the itemtype flag, so cond_passes = NO. The bug manifests regardless. Proposed fix: Merge the two if blocks back into one, so the pickup-location logic and $item->{available} assignment only execute when the current item individually passes all conditions. The global $valid_items accumulator for the post-loop check at line 661 is preserved: if ( !$item->{cantreserve} && !$exceeded_maxreserves && $can_item_be_reserved eq 'OK' && IsAvailableForItemLevelRequest( $item_object, $patron, undef ) ) { $valid_items = 1; my $pickup_locations = $item_object->pickup_locations( { patron => $patron } ); $item->{pickup_locations_count} = $pickup_locations->count; if ( $item->{pickup_locations_count} > 0 || C4::Context->preference('AllowHoldPolicyOverride') ) { $num_items_available++; $item->{available} = 1; ... } else { $item->{available} = 0; $item->{not_holdable} = "no_valid_pickup_location"; } } elsif ( C4::Context->preference('AllowHoldPolicyOverride') ) { ... } else { $item->{available} = 0; } -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7