December 2023 - Koha-bugs - lists.koha-community.org

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

[Bug 30043] New: Malformed records shown as not existing
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '26

12 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30043 Bug ID: 30043 Summary: Malformed records shown as not existing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org I just had a case where a batch MARC import script (not part of Koha, but maintained separately) had put some records with an empty 942 field into the database. The MARCXML looked something like this: <datafield tag="887" ind1=" " ind2=" "> <subfield code="a">x</subfield> </datafield> <datafield tag="942" ind1=" " ind2=" "> </datafield> <datafield tag="950" ind1=" " ind2="k"> <subfield code="a">y</subfield> </datafield> When trying to view these records, the following message was displayed: The record you requested does not exist But all the data were in the biblio, biblioitems, biblio_metadata tables. It was not possible to view the the record in the editor either. Would it be possible to catch this error and say something like "The record you requested has fatal errors" instead of telling the user it does not exist? Relevant code in catalogue/detail.pl: 78 my $record = GetMarcBiblio({ biblionumber => $biblionumber }); 79 my $biblio = Koha::Biblios->find( $biblionumber ); 80 $template->param( 'biblio', $biblio ); 81 82 if ( not defined $record ) { 83 # biblionumber invalid -> report and exit 84 $template->param( unknownbiblionumber => 1, 85 biblionumber => $biblionumber ); 86 output_html_with_http_headers $query, $cookie, $template->output; 87 exit; 88 } This reports unknownbiblionumber => 1 when $record is not defined, but it does not differentiate between "biblionumber does not exist" and "biblionumber points to a broken MARCXML record". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 17471] New: Borrower Previously Checked Out: Date of last checkout
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '26

12 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17471 Bug ID: 17471 Summary: Borrower Previously Checked Out: Date of last checkout 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: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When the dialog with previous checkout confirmation appers, there should be displayed the date of last checkout. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 18450] New: Renew in header bypasses hold block and renewal limits
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '26

12 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18450 Bug ID: 18450 Summary: Renew in header bypasses hold block and renewal limits Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation 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 When you renew an item on hold, it allows you to bypass the hold, even if you don't allow it elsewhere. It also bypasses renewal limits set in Circulation Rules. Does not honor AllowRenewalLimitOverride preference if set to Don't allow. Does not honor AllowRenewalIfOtherItemsAvailable if set to Don't allow. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 78

[Bug 31606] New: Enhance acquisitions to allow ordering on next year's budget when still in current year.
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '26

12 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31606 Bug ID: 31606 Summary: Enhance acquisitions to allow ordering on next year's budget when still in current year. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: rkuiper(a)roundrocktexas.gov QA Contact: testopia(a)bugs.koha-community.org Created attachment 140860 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=140860&action=e… Full description of problem of end-of-year processing & possible solution. The topic of end-of-year processing has come up regularly in the koha-us Acquisitions SIG. Librarians would like to have a way to order things for the next year when still in the current year and have the items showing up on the next year's budget. Example: our library has a fiscal year that goes from Oct 1 to Sept 30. A popular book will release October 15. We want to order the book in August. We would like to have the item ordered on the new fiscal year starting October. How do we do that? I have attached a Word document that more fully explains the issue and I have suggested a solution that I think will work for both EDI and non-EDI vendors. Please look over the solution and share any problems or improvements. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 62