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

[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 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

[Bug 42933] New: ERM - Error adding a license to an agreement when leaving non-mandatory fields empty
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42933 Bug ID: 42933 Summary: ERM - Error adding a license to an agreement when leaving non-mandatory fields empty Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk Target Milestone: --- If you add a license to an agreement, and leave all the non-mandatory fields empty you get this error message: Something went wrong: Error: Expected string - got null. If you select data for a non-mandatory field, then the change you made is saved and you don't get an error. If any of the fields when adding a license are required, then they should be marked as required. To reproduce: 1. Enable the ERM module: set the ERMModule system preference to 'Enable'. 2. Got to the ERM module. 3. Add a license: Licenses > New license - Complete the mandatory fields - Click 'Save' 4. Add a test agreement: Agreements > New agreement - Completed the required fields - Under the licenses section, click 'Add new license' - Select the license you created from the dropdown list for the 'Licenses' field - Don't add data for any another fields for the license - none are marked as mandatory - Click 'Save' - Get error with yellow background at the top of the page: "Something went wrong: Error: Expected string - got null." - Select a value for the status field, for example "Controlling" - Click 'Save' - The agreement is now created. This was identified when testing bug 37502. I searched the ERM module for Bugzilla, but couldn't see a bug reflecting this issue. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 42874] New: z3950_auth_search is loosing index parameter
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42874 Bug ID: 42874 Summary: z3950_auth_search is loosing index parameter Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- When adding an authority from within creating/editing a biblio the index param, which identifies the initial MARC field to fill can get lost when using z39.50 search: - when using pagination from a results list - when clicking Try another search is used. To recreate: - edit f.e. 262: /cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=262 - go to tab 7 and create a new 700 field (click on icon next to ADDED ENTRY--PERSONAL NAME - click on the icon te search for an authority (next to Personal name input field - check that the popup has a param like &index=tag_700_subfield_a_13631_9534947903 - click create new authority * - click Z39.50/SRU search * - on a result list every 'import' button still has index (via hovering the import button) - click on Go to page 1 - see result list again BUT the 'import' buttons do not have index param anymore - click back in browser to be on the former result list - click 'try another search' - check that new URL does not have index param anymore * all URLs still have the param index Importing one of the results without the index param would not update and link the biblio you originally edited -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14