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

[Bug 41803] New: Improvements to consistency in basket groups template
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41803 Bug ID: 41803 Summary: Improvements to consistency in basket groups template Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org I'd like to make a few changes to the basket groups template for consistency and validity. The main change is to make the basket group action buttons consistent with other tables in Koha with an "actions" column. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 42915] New: Filtering Holds table by patron name or pickup library is broken
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42915 Bug ID: 42915 Summary: Filtering Holds table by patron name or pickup library is broken 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: blawlor(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- To replicate: 1. Have holds on a bib for different patrons and pickup locations 2. Try filtering by a patron name or pickup location 3. See 'No matching records found' 4. Note: filtering by patron barcode still works This regression seems like it was introduced by bug 23269 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 79

[Bug 43069] New: Empty PatronDuplicateMatchingAddFields considers every new patron as duplicate
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43069 Bug ID: 43069 Summary: Empty PatronDuplicateMatchingAddFields considers every new patron as duplicate 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: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 43043] New: Library limit for OpacMySummaryNote HTML customization doesn't work
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43043 Bug ID: 43043 Summary: Library limit for OpacMySummaryNote HTML customization doesn't work Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When an OpacMySummaryNote HTML customization is limited to a single library, it doesn't display in patron accounts. The customization only shows when set to 'All libraries'. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 43121] New: Vue: Don't pattern match on translatable strings
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43121 Bug ID: 43121 Summary: Vue: Don't pattern match on translatable strings 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, matt.blenkinsop(a)openfifth.co.uk, me(a)paulderscheid.xyz Target Milestone: --- I think we've discovered a bad design pattern here, that crept into the Vue work: We sometimes match untranslatable strings on translatable strings, so they won't match in an installation that is not English. Example: koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: { name: "Ordering information", pane: 2 }, koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorResource.vue: group: $__("Ordering information"), I believe there are more occurences for this and we maybe need a coding guideline. In other cases we seem to have both translatable, which probably works, but still seems like a less than ideal pattern. We should be matching on things, that don't change between languages. Note: the problems in the vendor detail Vue is visible as a display bug (sequence of sections) in 26.05. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 43098] New: Typo in guided_reports_start.tt
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43098 Bug ID: 43098 Summary: Typo in guided_reports_start.tt Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Target Milestone: --- Commit Bug 34478 Add 'op' to reports/guided_reports added a typo in URL args : <a href="/cgi-bin/koha/reports/guided_reports.pl?op=edit_formid=[% id | uri %]" Should be : <a href="/cgi-bin/koha/reports/guided_reports.pl?op=edit_form&id=[% id | uri %]" Found with : git grep "op=[^& ]*=" -- '*\.tt' No match in perl files nor includes -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 43001] New: Non priority hold label doesn't always appear on reserve/request.pl
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43001 Bug ID: 43001 Summary: Non priority hold label doesn't always appear on reserve/request.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- To recreate: 1. Place a item level hold, making sure to mark it as "Non priority hold" 2. After placing the hold, on reserve/request.pl look at the "Details" column 3. Notice the hold is missing "Non priority hold" text in the details column -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[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 Aug '26

11 Aug '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 16

[Bug 42992] New: FTP file transport list_files() corrupts filenames
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42992 Bug ID: 42992 Summary: FTP file transport list_files() corrupts filenames Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Koha::File::Transport::FTP->_list_files parses the LIST / "ls -l" output returned by the FTP server. The date field in that output is three whitespace-separated tokens (Mon DD HH:MM, or Mon DD YYYY for older files), but the parse used a non-greedy capture that only consumed the first token (the month). The remaining two date tokens were left glued to the front of the filename, so every filename returned for an FTP transport was prefixed with the listing date, e.g. -rw-r--r-- 1 user group 1234 Jan 01 12:00 QUOTES_413514.CEQ becomes filename "01 12:00 QUOTES_413514.CEQ" Callers (Koha::Edifact::Transport and misc/cronjobs/marc_ordering_process.pl) then ask the server for a file that does not exist, so no files are downloaded, renamed or deleted over FTP. SFTP and Local transports are not affected. This regressed when EDI transport moved onto the file_transports system (bug 38489): the old Koha::Edifact::Transport::ftp_download listed files with Net::FTP->ls (NLST, bare names); the refactor switched to Net::FTP->dir (LIST) to return the richer hashref shape used by the SFTP and Local transports, but the parse was faulty. The fix consumes the date field explicitly as three tokens so the filename is captured cleanly (spaces preserved, directories still skipped). The LIST-based approach and the filename/longname/size/perms return shape are kept so the structure stays consistent across transport classes. Test plan: 1. prove t/db_dependent/Koha/File/Transport/FTP.t 2. Revert Koha/File/Transport/FTP.pm only and re-run: the list_files() subtest fails on the filename/size/perms assertions. 3. prove t/db_dependent/Koha/Edifact/Transport.t -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 42988] New: Saving a sip account imported from SIPconfig.xml can change the holds ( holds_get_captured ) behavior.
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42988 Bug ID: 42988 Summary: Saving a sip account imported from SIPconfig.xml can change the holds ( holds_get_captured ) behavior. Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The migration from the SIP config file to the database leaves holds_get_captured NULL which makes the behavior default to on, but in the sip account editor, the off option is selected so when you save the profile edit, the behavior is changed! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24