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

[Bug 41945] New: Patrons' Curbside Pickup history should be condensed or moved
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41945 Bug ID: 41945 Summary: Patrons' Curbside Pickup history should be condensed or moved Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: tech.aimee(a)salinapublic.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Created attachment 194003 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=194003&action=e… Test account profile shows curbside pickup indefinitely Currently, a patron's Curbside Pickup history sits on the front page of their profile forever. If the patron picks up often, since this does not condense, this clutters up their profile, hiding other notes and information from staff. It would be more helpful if the information condensed to show a few more recent dates on the front page or moved to live as a table in its own tab on the left side bar. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 28151] New: Missing documentation on variable "access_dir"
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28151 Bug ID: 28151 Summary: Missing documentation on variable "access_dir" Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: mik(a)adminkuhn.ch QA Contact: testopia(a)bugs.koha-community.org Bug 11317 introduced in Koha 18.05 a new variable "access_dir" which is nowhere documented in the Koha manual, as far as I could see. In new Koha installations the following can be found in "koha-conf.xml" <access_dirs> <access_dir></access_dir> <access_dir></access_dir> </access_dirs> but it is nowhere explained how to set or how to use these veriables. In older versions of Koha that are updated these variables are missing and as far as I can remember there is no notice that they should/could be added. However, if you click Koha menu "Tools > Access files" you will get the message: Error: Files could not be found because the "access_dir" option was not set in "koha-conf.xml". Contact your system administrator to add this option. There is section https://koha-community.org/manual/20.11/en/html/tools.html#access-files in the manual but it just says "The directories where the files are stored need to be defined in the koha-conf.xml file." without further explanation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 41879] New: Holds that move to a new bib can be unfillable
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41879 Bug ID: 41879 Summary: Holds that move to a new bib can be unfillable Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com If a library's 'Holds and bookings policies by item type' allows holds by patrons from any library, but pickup at the item’s home library only, holds can be moved from bib A to bib B in a way that makes them unfillable with no indication that they won't fill. Currently, when the hold is moved from bib A to bib B, the hold pickup location will not automatically update to reflect the rule, and there is no notice that the rule has been broken. Scenario: -ReservesControlBranch is set to 'item's home library' -Main library's 'Holds and bookings policies by item type' for the itype BOOK is set to allow holds from patrons from any library, but pickup at Main only -Bib A is owned by North library, and bib B is owned by Main. Both are the item type BOOK, and each has one item on the bib. Steps: -Place a hold for a North patron on bib A for pickup at North -Move the hold to bib B -Note that the hold moves successfully, and is still set for pickup at North When the hold moves, there is no indication that the item will never trigger to send to North due to Main's 'Holds and bookings policies by item type'. The only way staff would realize that the hold will never fill is if they drop down the pickup locations for the moved hold and see the flag indicating that the current location isn't allowed. The move should either fail (as it does if the target record only allows holds from patrons matching the item’s home library per 'Holds and bookings policies by item type'), or staff should be forced to select a valid pickup location in order to complete the move. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 39215] New: EDIFACT quote files should skip orders that cannot be processed rather than failing to complete
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '26

26 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39215 Bug ID: 39215 Summary: EDIFACT quote files should skip orders that cannot be processed rather than failing to complete Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org When loading an EDIFACT quote file, if the process finds problematic data (usually a mismatched LLO - Branchcode or other enumerated coded field) the load process gets stuck and displays as 'Processing' in the EDFACT messages page. This usually means that the remainder of the quotes in the file have to be manually corrected and is it's currently difficult to debug by library staff. It would be preferable if the process could skip, and report any problem data but complete all other quotes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

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