May 2022 - Koha-bugs - lists.koha-community.org

[Bug 7107] 'used in' column on analytics not populating
by bugzilla-daemon＠bugs.koha-community.org 26 May '22

26 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7107 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|NEW |RESOLVED CC| |nick(a)bywatersolutions.com --- Comment #13 from Nick Clemens <nick(a)bywatersolutions.com> --- 677  678 <index_subfields tag="773" subfields="9"> 679 <target_index>Host-Item-Number:w</target_index> 680 </index_subfields> Works for me in both ES and Zebra (In reply to Joy Nelson from comment #11) > On a site that is 3.18.06 I am seeing the 'Used in X analytic' data in the > column. However the link is invalid. The link has this language: > /cgi-bin/koha/catalogue/search.pl?idx=hi&q=181290 > > > The 181290 is the item number. The itemnumber is not in the HI (hostitem) > index. When the link is clicked, no results are returned. > > Joy > > > (In reply to Nicole C. Engard from comment #10) > > This is version 3.6, 3.8, 3.10 and master. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 21517] New: OAI returns records outside of specified time range.
by bugzilla-daemon＠bugs.koha-community.org 26 May '22

26 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21517 Bug ID: 21517 Summary: OAI returns records outside of specified time range. Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: rudolfbyker(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 80225 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=80225&action=ed… The XML output of the OAI-PMH request. Example: http://brutus.local:8092/cgi-bin/koha/oai.pl?verb=ListRecords&metadataPrefi… Output contains results from 2014. Attached. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 27946] New: Add a charge per article request to patron categories configuration
by bugzilla-daemon＠bugs.koha-community.org 26 May '22

26 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27946 Bug ID: 27946 Summary: Add a charge per article request to patron categories configuration 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We propose adding a charge field (scan fee) to the patron category configuration screen. Cost for Article scan request: $____ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 125

[Bug 30841] New: Responsiveness not working for some screen sizes on OPAC search results
by bugzilla-daemon＠bugs.koha-community.org 25 May '22

25 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30841 Bug ID: 30841 Summary: Responsiveness not working for some screen sizes on OPAC search results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Between 768 and 991 pixels, the "Refine your search" area gets pushed to the very bottom of the page. Instead, it should either hide it (if min-width is below 768px) or we should show it side-by-side using 16.667% and 83.333% for the two columns (as we do with min-width of 992px. I don't know why .order-md-first and .order-first are used for the main search result area either as it seems completely unnecessary? -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 29441] New: We should make our method returns consistent in Koha::Biblio
by bugzilla-daemon＠bugs.koha-community.org 25 May '22

25 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29441 Bug ID: 29441 Summary: We should make our method returns consistent in Koha::Biblio Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We now have a few of 'get_marc_*' accessors in Koha::Biblio, but their returns are really inconsistent. I feel like we aught to try and make them as consistent as possible so future developers can use them without having to dig through the code to see what they return. In `get_marc_notes` we return an array of note strings from the marc record.. these may be selective subfield concatenations and could be in various orders. In `get_marc_host` we return either a Koha::Biblio object or the Biblio object + the subfield g, as a string, from the current records marc21 773 field we used to find the host. In `get_marc_components` we return an array of MARCXML strings. I think we could do better here.. certainly with the `_components` and `_host` routines either consistently returning Koha::Biblio/Koha::Biblios or MARCXML string/strings for example. As for `get_marc_notes`, this is a little different.. we could possibly return an array of MARC::Field objects for later processing, or perhaps we aught to have a second naming scheme for returning strings from MARC/Metadata vs retuning a marc/metadata object/string itself? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 20608] New: Elasticsearch - relevancy weights proposition for unimarc in mappings.yaml
by bugzilla-daemon＠bugs.koha-community.org 25 May '22

25 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20608 Bug ID: 20608 Summary: Elasticsearch - relevancy weights proposition for unimarc in mappings.yaml Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: claire.hernandez(a)biblibre.com This is the mappings updated in mappings.yaml see bug 18316 for the code evolution. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 27770] New: ES: Deprecated aggregation order key [_term] used, replaced by [_key]"
by bugzilla-daemon＠bugs.koha-community.org 24 May '22

24 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27770 Bug ID: 27770 Summary: ES: Deprecated aggregation order key [_term] used, replaced by [_key]" 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: victor(a)tuxayo.net Will be needed for ES 7 prove t/db_dependent/Koha/SearchEngine/Elasticsearch/Search.t [DEPRECATION] Deprecated aggregation order key [_term] used, replaced by [_key] - In request: {body => {aggregations => {subject => {terms => {field => "subject__facet",include => "[eE][aA][sS][yY].*",order => {_term => "asc"},size => 1000}}},from => 0,query => {query_string => {query => "*"}},size => 0},ignore => [],method => "GET",mime_type => "application/json",path => "/koha_kohadev_mydb/_search",qs => {},serialize => "std"} -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 13665] Retrieve facets from zebra is slow
by bugzilla-daemon＠bugs.koha-community.org 24 May '22

24 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13665 --- Comment #10 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Tomás Cohen Arazi from comment #9) > David, whlie you're digging that hole... One of the problems for the facet > retrieval step in Koha is that we look through the defined facets instead of > fetching them all at once. > > The reason behind that is that if some facet is not populated at all (i.e. > no record has field X which is mapped to the facet) then the resultset is > always empty in Zebra. I filed an issue about that (a lot of time ago) but > the answer was negative: that's the expected behavior. Yeah, I've been thinking a little bit about that as well, although I didn't look at the code for that. I think that's probably handled within the facet_fetch() function. I do wonder if they'd be interested in adding the "14" attribute to the faceting as well. (https://software.indexdata.com/zebra/doc/querymodel-zebra.html#querymodel-z…) Adam is out of the office this week, but I'm hoping that he'll help me to understand the faceting code. > So, would it be possible to add some ghost record (e.g. ID = -1) with all > the fields (one space or special character?) so we convert it into one query > instead of many? I think that might be an option. When I run zebrasrv in this directory https://github.com/indexdata/idzebra/tree/master/examples/marcxml, I noticed that there were records that weren't indexed and records that seemed to have empty indexes. In theory, we could add a record to Zebra like you describe, but I haven't tested it in practice. -- I wouldn't mind looking at trying to fetch the facets asynchronously although that's less pressing for me atm... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 30141] New: ElasticsearchCrossFields enabled returns no search results on OPAC
by bugzilla-daemon＠bugs.koha-community.org 24 May '22

24 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30141 Bug ID: 30141 Summary: ElasticsearchCrossFields enabled returns no search results on OPAC 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org ElasticsearchCrossFields is a great syspref to enable if you need to search across indexes, for example your search term includes both title and author keywords. We've discovered this only works on the staff client, and returns no results when searching on the OPAC. After some investigation, this is because the OPAC will add a `suppress:false` to the search query, to hide records that are suppressed in OPAC. I'm not sure why, but this combination of suppress:false and ElasticsearchCrossFields means no results are returned in the OPAC. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 18316] New: Add weighting/relevancy options to ElasticSearch
by bugzilla-daemon＠bugs.koha-community.org 24 May '22

24 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18316 Bug ID: 18316 Summary: Add weighting/relevancy options to ElasticSearch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 167