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

[Bug 43220] New: Patron name and card number should not be clickable in headings
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43220 Bug ID: 43220 Summary: Patron name and card number should not be clickable in headings Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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: 29768 Target Milestone: --- Since Bug 29768 the patron name and card number in the sidebar of patron pages is linked to the patron detail page. On the checkout page the patron name in the main heading is also clickable. This change happened in Bug 29768, "hidepatronname hides guarantor name on borrower edit screen." I think this was unintended and should be considered a bug. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29768 [Bug 29768] hidepatronname hides guarantor name on borrower edit screen -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 42108] New: Add ability to specify that a report can only be run as a foreground or background report
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42108 Bug ID: 42108 Summary: Add ability to specify that a report can only be run as a foreground or background report Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Building on bug 41921, it would be useful to be able to specify a report can only run as a background report for long-running reports. For the sake of completeness, we could also add the ability to specify reports as being foreground-only reports as well. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 42503] New: Optimize retrieval and display of the holds queue
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42503 Bug ID: 42503 Summary: Optimize retrieval and display of the holds queue Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement 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 The holds queue page (view_holdsqueue.pl) should be reworked to fetch data via API to improve performance for large systems. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 138

[Bug 41430] New: Retire the patron account flags
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41430 Bug ID: 41430 Summary: Retire the patron account flags Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com It seems odd to have two very specific account flags on patron accounts. We can accomplish the same task with patron restrictions (debarments). I would suggest we retire the patron account flags, and migrate any active flags to restrictions. Furthermore, we could create predefined restrictions, much like we have with predefined notes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 35337] New: Patron flags should be transitioned over to restrictions
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35337 Bug ID: 35337 Summary: Patron flags should be transitioned over to restrictions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The existence of patron flags seem arbitrary, like leftovers from before restrictions. It seems like you could accomplish the same thing with just restrictions. I would suggest removal of the flags, and incorporate a Authorized Value that could be customized with preset restrictions, including the former flags. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 35754] New: Place multiple item-group holds at once for the same record
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35754 Bug ID: 35754 Summary: Place multiple item-group holds at once for the same record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With the availability for item-groups and item group holds it make it very easy for patrons to place a hold on a group of items. This enhancement would provide an option to place multiple item-group holds for the same record. An example use case could be a patron wants to place a hold on volume 4, 5, and 6. Current behavior requires the user to place a hold for vol 4, then place another for vol 5, then finally place a hold for vol 6. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 41780] New: Show firstname if preferred_name is empty in moremember.tt
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41780 Bug ID: 41780 Summary: Show firstname if preferred_name is empty in moremember.tt Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: ayoub.glizi-vicioso(a)inLibro.com Reporter: ayoub.glizi-vicioso(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 28633 Since bz28633, the patron's firstname is no longer displayed in the staff interface (moremember.tt) if the 'preferred_name' field is NULL or empty. This issue occurs when patrons are imported via external scripts (like Activitek) that do not automatically populate 'preferred_name' with the 'firstname' value. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28633 [Bug 28633] Add a preferred name field to patrons -- You are receiving this mail because: You are watching all bug changes.

1 83

[Bug 40157] New: OAI's CSS should be updated to Bootstrap 5
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40157 Bug ID: 40157 Summary: OAI's CSS should be updated to Bootstrap 5 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The current files are dated (bootstrap 3) and contain http links to fonts which cause the OAI page to be displayed as insecure. -- You are receiving this mail because: You are watching all bug changes.

1 1

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

07 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 36

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

07 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 23