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

[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

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

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

[Bug 43336] New: Remove support for LibrisSpellcheck
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43336 Bug ID: 43336 Summary: Remove support for LibrisSpellcheck Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The Swedish National Library has discontinued the "bibspell" API that used to live at http://api.libris.kb.se/bibspell/ on which the LibrisSpellcheck feature was built, so we need to remove this feature from Koha. This should include at least: - The code - The sysprefs LibrisKey and LibrisURL - Settings for LibrisSpellcheck in the syspref OPACdidyoumean MariaDB [koha_kohadev]> select * from systempreferences where variable = 'opacdidyoumean'\G *************************** 1. row *************************** variable: OPACdidyoumean value: [{ "name": "AuthorityFile"}, { "name": "ExplodedTerms"}, { "name": "LibrisSpellcheck"}] options: NULL explanation: Did you mean? configuration for the OPAC. Do not change, as this is controlled by /cgi-bin/koha/admin/didyoumean.pl. type: Free $ grep -rn LibrisSpell * Koha/SuggestionEngine/Plugin/LibrisSpellcheck.pm:1:package Koha::SuggestionEngine::Plugin::LibrisSpellcheck; Koha/SuggestionEngine/Plugin/LibrisSpellcheck.pm:27: return 'LibrisSpellcheck'; Koha/SuggestionEngine/Plugin/LibrisSpellcheck.pm:68:Koha::SuggestionEngine::Plugin::LibrisSpellcheck koha-tmpl/intranet-tmpl/prog/en/modules/admin/didyoumean.tt:24: [% CASE 'LibrisSpellcheck' %] -- You are receiving this mail because: You are watching all bug changes.

1 31

[Bug 43211] New: Koha hungs when receiving order with AcqCreateItem set to 'receiving an order'
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43211 Bug ID: 43211 Summary: Koha hungs when receiving order with AcqCreateItem set to 'receiving an order' Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com Blocks: 41563 Target Milestone: --- Koha hangs when receiving an order with AcqCreateItem set to "receiving an order". The JavaScript console shows: Uncaught TypeError: unique_item_fields.split is not a function This is most likely caused by the changes introduced in bug 41563. Koha.addPrefs({ [...] UniqueItemFields: [% Koha.Preference('UniqueItemFields') ? 1 : 0 | html %], }); UniqueItemFields should not be reduced to a number. It is expected to be a string containing a list of item fields separated by pipes (|), which is why the code later calls split() on it. To reproduce: 1. Create a basket and set "Create items when" to "receiving an order". 2. Add an order and close the basket. 3. Attempt to receive the order. Koha will most likely hang. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41563 [Bug 41563] Tidy kohaTable block - acqui -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 42350] New: modborrowers.pl needs to include options for preferred & other name, and middle name field
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42350 Bug ID: 42350 Summary: modborrowers.pl needs to include options for preferred & other name, and middle name field 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 Batch patron modifications should include a preferred name and other name reset options next to the first name field. I'm also noticing that middle name is not provided in the batch modification. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 40096] New: Add salutation/ borrowers.title to batch patron modification
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40096 Bug ID: 40096 Summary: Add salutation/ borrowers.title to batch patron modification Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: PC OS: Windows Status: NEW Severity: enhancement Priority: P1 - high Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com, sonia.bouis(a)univ-lyon3.fr CC: sonia.bouis(a)univ-lyon3.fr Salutation/ borrowers.title is an older field that libraries sometimes have data in as a result of migrated data or prior library policy, but it's not the easiest to get in and modify out once they no longer want it. It would be nice if salutation was a field in batch patron modification, either for the ability to update in bulk if a library IS using titles, or to be able to easily blank out values there if the library no longer wants them. Perhaps the field could only display if BorrowersTitles is enabled, at least until 11815 is unblocked, and then conditions could be revisited. --- Comment #1 from Sonia Bouis <sonia.bouis(a)univ-lyon3.fr> --- + 1 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

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