September 2024 - Koha-bugs - lists.koha-community.org

[Bug 23668] New: Information on syntax for patron attributes
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '26

13 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23668 Bug ID: 23668 Summary: Information on syntax for patron attributes Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: anke.bruns(a)gwdg.de QA Contact: testopia(a)bugs.koha-community.org In the manual at https://koha-community.org/manual//19.05/en/html/tools.html#patron-import-l… the syntax for multiple patron attributes which, to complicate things, consist of multiple words separated by blanks isn't described correctly. It says: <citation> "Note If loading patron attributes, the ‘patron_attributes’ field should contain a comma-separated list of attribute types and values. The attribute type code and a colon should precede each value. For example: “INSTID:12345,BASEBALL:Cubs” This field must be wrapped in quotes if multiple values are defined. Since values can contain spaces, additional doubled-quotes may be required: “INSTID:12345,BASEBALL:Cubs,””BASEBALL:White Sox”” " </citation> After trying this, and all other possible combinations of attributes and quotes I could come up with, I found that import only works if the attributes are entered in the most simple way, namely in single quotes. The blanks can be which, for the above example, would read: “INSTID:12345,BASEBALL:Cubs,BASEBALL:White Sox” I didn't test exactly this combination of attributes, but with similar ones it worked. If this can be confirmed, maybe the manual can be updated accordingly? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 30295] New: Send a notification when a recall is manually cancelled
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '26

13 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30295 Bug ID: 30295 Summary: Send a notification when a recall is manually cancelled 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The process would be: 1. Recall is cancelled by library staff or the requester. 2. Notification of the recall cancellation is sent via email and SMS to the recall requester. So it would be exactly the same as the HOLD_MANUAL_CANCEL notice that we currently have for reserves, only relevant to recalls. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 112

[Bug 28182] New: Elastic search exact authorities search includes punctuation
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '26

13 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28182 Bug ID: 28182 Summary: Elastic search exact authorities search includes punctuation Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com Bug 26533 fixes the 'exact' search option to search exactly This reveals that the ES search includes punctuation In koha testing docker search for: Addison-Wesley professional computing series And then: Addison-Wesley professional computing series. You get different records -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 28884] New: ElasticSearch: Question mark in title search returns no results
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '26

13 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28884 Bug ID: 28884 Summary: ElasticSearch: Question mark in title search returns no results Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: jyorio(a)equinoxinitiative.org When searching for a title with a question mark, Who's Afraid of Virginia Woolf? for example, Koha returns no results with ElasticSearch. Removing the question mark or escaping it retrieves results, as does enclosing the entire title with the question mark in quotes. Since ? is a wildcard for ElasticSearch, this may be expected behavior (I'm not sure that it is or isn't), but explaining to patrons that they need to change their search behavior can be a big ask for libraries. Not sure what the best option is. Perhaps a system preference to automatically escape ? and not treat it as a wildcard for those libraries who would prefer that? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 62

[Bug 33260] New: Show message queue on staff interface and make notices printable
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '26

13 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33260 Bug ID: 33260 Summary: Show message queue on staff interface and make notices printable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Some Koha libraries need to get messages out to borrowers who do not have email addresses, so they need to be able to view generated notices, and optionally print them so they can be delivered offline. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 852

[Bug 31406] New: Set focus for cursor to setSpec input when adding a new item search field
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '26

13 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31406 Bug ID: 31406 Summary: Set focus for cursor to setSpec input when adding a new item search field Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When adding a new item search field from administration, the focus/cursor should be in the first field of the entry form: Name -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 38023] New: Add ability to exclude certain item types for advance_notice.pl
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '26

13 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38023 Bug ID: 38023 Summary: Add ability to exclude certain item types for advance_notice.pl Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Libraries often request that certain item types not be reported upon in an advance notice. It's pretty trivial to exclude them from a DUE or PREDUE with TT but the digest ones are not as easy. Would be nice if there was an flag in the cron to exclude. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 35052] New: OpacHiddenItemsHidesRecord system preference should be considered on index time instead
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '26

13 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35052 Bug ID: 35052 Summary: OpacHiddenItemsHidesRecord system preference should be considered on index time instead Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: alexander.blanchard(a)ptfs-europe.com, dcook(a)prosentient.com.au, jacob.omara(a)ptfs-europe.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com Currently, results are being skipped after the search has been processed in C4/Search.pm. This may cause several unintended scenarios: 1) The first page has all the results skipped, even thought there are more results in 2nd page and so on, this will will result in a "No search results" page 2) The total search results number still shows 80 (for example), even if it has skipped 70 and is only showing 10. To reproduce we need to use both OpacHiddenItems and OpacHiddenItemsHidesRecord Use OpacHiddenItems and put some rules that hide some items Use OpacHiddenItemsHidesRecord = 'hide' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 32707] New: ElasticSearch should not auto truncate (even if QueryAutoTruncate = 1) for identifiers (and some other fields)
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '26

13 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32707 Bug ID: 32707 Summary: ElasticSearch should not auto truncate (even if QueryAutoTruncate = 1) for identifiers (and some other fields) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com Koha with Zebra prevented auto truncation in some circumstances -- see the first return for ccl inside C4::Search:: buildQuery, before applying auto truncation, and setting $auto_truncation = 0 for some search fields. Koha with ElasticSearch applies auto truncation for all search fields, not paying attention to these special cases when it should not be done. This leads to various problems as described in bug 26508, 26608, etc. The solution would be to prevent auto truncation for certain search fields, above all – the identifiers. In addition, under no circumstances should a search field other than of text type be truncated (an attempt to truncate would generate an exception from ElasticSearch, e.g. number_format_exception for integer). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 63

[Bug 24143] New: buildQuery should disable Query* on identifier search
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '26

13 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24143 Bug ID: 24143 Summary: buildQuery should disable Query* on identifier search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Currently, QueryWeightFields, QueryFuzzy, QueryStemming, QueryAutoTruncate are disabled in buildQuery in several cases: - Date of Publication - Date of Acquisition - ISBN,ISSN,Standard Number Those modifiers should also be disabled when searching on identifiers. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21