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

[Bug 42882] New: Add option to disable setting time and permissions for File Transports
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42882 Bug ID: 42882 Summary: Add option to disable setting time and permissions for File Transports Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Some vendors don't allow the SFTP use to change the time and permissions on uploaded files. This results in the error "Couldn't setstat remote file: General failure at /usr/share/koha/lib/Koha/File/Transport/SFTP.pm line 97." for SFTP transports. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 49

[Bug 28593] New: Add ability to charge lost fee when applying new lost status when resolving a claim
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28593 Bug ID: 28593 Summary: Add ability to charge lost fee when applying new lost status when resolving a claim Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 28271 Bug 28271 added the ability to apply a new lost status when resolving a claim. We should also add the ability to charge a replacement fee. Many libraries do not charge a replacement fee when a claim is generated. If the item is not found within the time period allowed by library policy, then the item is assumed lost, the claim is resolved, and the item is set to lost. At that point, the library would like to charge the patron. As things stand, there is not a way to generate a lost fee tied to that issue_id. You'd have to either create a manual invoice or return the item, check it back out to the patron, and mark it lost again. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28271 [Bug 28271] Add the ability to set a new lost status when a claim is resolved -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 39780] New: Update library groups form to use grid layout
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39780 Bug ID: 39780 Summary: Update library groups form to use grid layout Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 39483 Building on Bug 39483, I'm working to convert the library groups forms to the new grid layout. This will include some changes to the .fg form grid to allow for defining a couple of different widths for the input grid item and to convert the grid-related media queries to be container queries instead. This allows the form grid to be responsive based on width of the the container (<fieldset) rather than the width of the page. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39483 [Bug 39483] Update staff interface forms to use grid layout -- You are receiving this mail because: You are watching all bug changes.

1 59

[Bug 42018] New: Inconsistent behavior for null values for fields selected in PatronDuplicateMatchingAddFields
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42018 Bug ID: 42018 Summary: Inconsistent behavior for null values for fields selected in PatronDuplicateMatchingAddFields Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com PatronDuplicateMatchingAddFields behaves differently for null values depending on whether the null values are in the existing patron record or the record being created. To replicate: -Set PatronDuplicateMatchingAddFields to surname, firstname, email Scenario 1: -Create patron A with a first name and surname, but null email -Create patron B with a first name and surname matching patron A, but a value in email -----> NOT FLAGGED as duplicate Scenario 2: -Create patron A with a first name, surname, and email -Create patron B with a first name and surname matching patron A, but null email -----> FLAGGED as duplicate It seems that the two scenarios should behave the same way, or that there should be documentation of the different behavior in the manual. This applies to 40082 but is also true for duplicate matching in the staff interface. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 42700] New: In C4/SIP/ILS/Patron.pm, hold_items only counts waiting holds
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42700 Bug ID: 42700 Summary: In C4/SIP/ILS/Patron.pm, hold_items only counts waiting holds Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I can't find good documentation on this, but I think this is a bug: hold_items => $flags->{WAITING}->{itemlist}, holds_items is currently a count of waiting holds, when it should total holds. Meanwhile unavail_holds is a count of all holds except waiting holds. Some 3rd party SIP machines use this calculation to get a count of "holds to pick up": holds ready for pickup = hold_items - unavail_holds Currently this can produce a negative number. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 43072] New: Hold policies display incorrectly in circ rules page
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43072 Bug ID: 43072 Summary: Hold policies display incorrectly in circ rules page 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Depends on: 41267 Target Milestone: --- Bug 41267 added a new hold policy type to the "Default holds and bookings policies by item type" section at the bottom of the page, "Fill other record level holds on record at checkout." If this policy is set to Yes or undefined, an item of the given itemtype can fill a bib-level hold even if the itemtype doesn't otherwise allow holds. If the policy is set to No, then the itemtype will not fill record-level holds. On upgrade, Bug 41267 does not set anything in the circulation_rules for this policy. After upgrade, any itemtype that has a value set for something else in this section will show a value of "No" for "Fill other record level holds on record at checkout" even though this policy isn't actually set. So the upgrade doesn't actually change any circ behavior, but it shows an erroneous change in the circ rules. To recreate: - be on a version of Koha without this code (25.11.04 or older) - set Hold Policy = "No holds allowed" for an itemtype - upgrade Koha to a version with this code - reload the circ rules page, confirm the Default holds and bookings policies by item type section still shows your Hold Policy value and *also* shows "Fill other record level holds on record at checkout" set to "No" for your itemtype - query "select * from circulation_rules where rule_name='fill_other_biblio_holds_policy'" and confirm no rule exists in the database - confirm a record-level hold can still be filled with an item of your itemtype - update your circ rules to actually save a No for "fill other record level holds" - confirm this now shows in your circ rules query - confirm a hold no longer fills It seems simplest to make this table show "Yes" when no policy exists. But on the other hand in current main I cannot set any rule in this table without also setting a "Fill other record level holds" value, so maybe it would be more consisten to actually save a "Yes" rule for 'fill_other_biblio_holds_policy' on any itemtype that already has something set for any other rule here. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 [Bug 41267] It should be possible to prevent some itemtypes from filling other biblio level holds -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

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

26 Oct '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 24

[Bug 40668] New: Library groups and seperateholdings with itemgroups prevents adding items to itemgroup
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40668 Bug ID: 40668 Summary: Library groups and seperateholdings with itemgroups prevents adding items to itemgroup Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: 1. On a single record, create at least 20 items at Centerville, 10 at Fairfield, 10 at Fairview 2. create a library group that has Fairfield and Fairview and check Limit item editing to items owned inside of this group. 3. Enable EnableItemGroups & SeparateHoldings 4. Set a patron (I used Henry) to have a password you know and the following permissions: -Staff access (catalogue) -Edit Catalog -Edit Items -Create, update and delete item groups, add or remove items from an item group 5. Set their library to Fairfield 6. Create an item group on your record. 7. In another browser/guest window, log in as your patron from step 4. 8. Navigate to your record. 9. Navigate to the "Other holdings" page, there should be no checkboxes. 10. Use the filters or the table search to filter to Fairview, there should now be checkboxes. 11. If you click a checkbox, you are not shown the section: Actions: Add/move to item group Remove from item group The check only happens when the table loads based on if the first page of results has s selectable items or not. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 43177] New: Use archived link for Bridge Material Type Icon Set
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43177 Bug ID: 43177 Summary: Use archived link for Bridge Material Type Icon Set Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: About Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The page for the Bridge Material Type Icon Set no longer exists, but the Internet Archive has a saved version: https://web.archive.org/web/20240729104520/https://apps.carleton.edu/campus… -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 43078] New: File transport SFTP backend returns inconsistent list() structure compared to FTP/Local backends
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43078 Bug ID: 43078 Summary: File transport SFTP backend returns inconsistent list() structure compared to FTP/Local backends Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The polymorphic file transport classes (FTP, SFTP, Local) are intended to provide a consistent API across transport backends, wrapping existing CPAN modules (Net::FTP, Net::SFTP::Foreign) alongside a local filesystem implementation. The list() method on the FTP and Local backends returns an array of flat hashrefs, each containing file metadata (filename, size, modification time, etc.). The SFTP backend, however, returns metadata partially nested inside Net::SFTP::Foreign::Attributes objects, as this is the native return structure from Net::SFTP::Foreign. This means callers of list() currently need to know which backend they're talking to in order to correctly extract file metadata, which defeats the purpose of the shared API. Steps to reproduce: Instantiate the FTP or Local transport class and call list() on a directory Instantiate the SFTP transport class and call list() on the same logical directory Compare the structure of returned metadata — SFTP results include nested attribute objects; FTP/Local do not Expected behaviour: All three backends return metadata in the same flat hashref structure for a given list() call. Suggested fix: Flatten the relevant fields out of Net::SFTP::Foreign::Attributes (size, mtime, permissions, etc.) into the same flat hash shape used by the other two backends, within the SFTP wrapper class. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25