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

[Bug 32940] New: [Bug 30280 follow-up] Subject-heading-thesaurus-conventions search field missing in Zebra
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32940 Bug ID: 32940 Summary: [Bug 30280 follow-up] Subject-heading-thesaurus-conventions search field missing in Zebra Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P2 Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: frank.hansen(a)ub.lu.se, katrin.fischer(a)bsz-bw.de In the bug 30280 a new searchfield Subject-heading-thesaurus-conventions has been introduced for ElasticSearch (indexing 040 $f of an authority record). This searchfield is used in C4::Heading::_search with an alias thesaurus-conventions (introduced with the same bug and defined only in Koha/SearchEngine/Elasticsearch/QueryBuilder.pm). At the same time, neither Subject-heading-thesaurus-conventions nor thesaurus-conventions are defined for Zebra. As a result, while performing a linking (with link_bibs_to_authorities.pl for instance) of a biblio 6XX field with 2nd indicator == 7 and proper $2 (e.g. 650 _7 $a Ekonomia $2 DBN) with Zebra engine we get: error: Unsupported Use attribute (114) thesaurus-conventions Bib-1 On the other hand, according to the stable Zebra configuration (for 15 years or so) Koha inserts 040 $f into the Subject-heading-thesaurus index, as goes there 008/11 byte, transformed in the following way: a => lcsh b => lcac c => mesh d => nal k => cash n => notapplicable r => aat s => sears v => rvm So, maybe ES should go the same way? If for some reasons no, the Koha part should be modified accordingly. It seems that changes made in Koha in favour of the ES should always be very carefully checked in Zebra context... Now the linking feature in Zebra does not work in most cases (also described in the bug 32916). Seeing the comment at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30280#c58, I understand that the enhancement is still not mature enough. So, I am wondering that it has been accepted in the released version (22.11.00)... Was this not by mistake? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 27113] New: ElasticSearch: Autocomplete in input search
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27113 Bug ID: 27113 Summary: ElasticSearch: Autocomplete in input search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: ivan.dziuba(a)inlibro.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 302

[Bug 22730] New: Not possible to set default value for patron attributes
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22730 Bug ID: 22730 Summary: Not possible to set default value for patron attributes Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: rhouk(a)ottumwapubliclibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- It would be helpful to be able define default values for patron attributes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 40076] New: Add --skip-no-email parameter to borrowers-force-messaging-defaults.pl
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40076 Bug ID: 40076 Summary: Add --skip-no-email parameter to borrowers-force-messaging-defaults.pl Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz I use this script a lot during migrations to set the default preferences from the categories to all the patrons. However, recently I've had cases where about half the patrons did not have email addresses in their accounts. This means that I either set everyone's preferences and the library has to go back and remove the preferences from the patrons without email addresses, or I don't do it, and the library has to set the preferences for those with email addresses. (I think I've had back-to-back cases like this because in their old system it was set up as if the patron has an email address, they get the email notices, and if they want to opt-out, they remove their email address from their account.) It would be great if the script could skip the patrons without email addresses. (Note : we never set SMS messages by default, only email; I don't know if someone does this, but it is not a requirement for us to manage sms messaging with this script.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 39781] New: Cannot limit by library when creating custom patron email sent via patron details page
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39781 Bug ID: 39781 Summary: Cannot limit by library when creating custom patron email sent via patron details page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 29393 To recreate: 1 - create a new notice in module "Patrons (custom message)" 2 - limit your notice to a library 3 - give your notice content for the email format 4 - go to a patron record, select Add Message 5 - confirm the notice you created appears as an option regardless of whether or not you're logged in at the branch you selected in step 2 6 - confirm the Save button fails to enqueue your notice, regardless of logged-in branch We don't pass any branchcode along with the borrowernumber and letter_code when enqueueing this, so it fails if the notice template is limited to a branch. We should send the logged-in library when enqueueing the notice. We should also high the notice from the Add Message form if the user is not logged in at the correct branch. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29393 [Bug 29393] Ability to send emails from patron details page -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 42083] New: Email and SMS messages from patron record should have distinct permissions
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42083 Bug ID: 42083 Summary: Email and SMS messages from patron record should have distinct permissions Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 40933, 29393 Bug 29393 added the ability to send email from a patron's record. 40933 expanded that to SMS. But they currently share a single permission. It would be preferable for those to be two distinct permissions. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29393 [Bug 29393] Ability to send emails from patron details page https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40933 [Bug 40933] Add SMS support under Add message feature -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 39207] New: Improve usability of search when holding a specific item
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39207 Bug ID: 39207 Summary: Improve usability of search when holding a specific item Change sponsored?: --- 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: lauri.hanninen(a)lahti.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 178779 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=178779&action=e… Image showing how user's set library blocks filtering due to allowed pickup locations When filtering for a specific item on holds page using the search bar, it's currently not feasible to filter by user's set library. When entering the user's set library in the search field, search results won't narrow down because they include the active selection in the Allowed pickup locations column which by default is the user's set Library. Filtering by user's own library would be one of the common usages for the search field when placing a hold on a specific item, so it would have more usability if it could be fixed. See attached image as an example. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 41640] New: Optional way to log multiple local uses with statistical patron
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41640 Bug ID: 41640 Summary: Optional way to log multiple local uses with statistical patron Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Libraries would like a way to be able to optionally count multiple local uses at once, especially for workflows where things are recorded at end of day. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 27635] New: Add option for patron to view archived suggestions on the OPAC
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27635 Bug ID: 27635 Summary: Add option for patron to view archived suggestions on the OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 22784 added the ability to archive suggestions on the staff interface. It would be nice to allow patrons to view their archived suggestions -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 36596] New: Opening/closing hours should be forced to be set together
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '26

10 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36596 Bug ID: 36596 Summary: Opening/closing hours should be forced to be set together Change sponsored?: --- Product: Koha Version: master 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It only seems to make sense to set a closing hour if an opening hour has been set, otherwise it would be open 24 hs :-D A method needs to be added to Koha::Library: * set_hours( $dow, $opening, $closing ) * The method needs to throw an exception if one of them is not passed * If none is passed then it means the library would not be open, and then all hours for the * The code for setting the hours in branches.pl should be removed and this method used instead * The method MUST BE COVERED BY TESTS NOTE: I don't personally like the chosen column name 'day'. I would use either 'dow' or 'day_of_week'. And it should be clear which one is the first in the comments. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7