February 2021 - Koha-bugs - lists.koha-community.org

[Bug 27762] New: Do not save OpacHiddenItems preferences
by bugzilla-daemon＠bugs.koha-community.org 07 May '21

07 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27762 Bug ID: 27762 Summary: Do not save OpacHiddenItems preferences Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: jcautomatizacion(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Hello, When I try to change the preferences of the OpacHiddenItems system, Koha does not let me save, it indicates an internal error, I want to leave only these: itype: [AUDIOVISUA, COMPUADOR, COMPUTEC, EQUIPOSBIB, INTERBIB, NOVEDAD, MATDIDACT, MATELECTR] location: [ACQUISITION] -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 26373] New: Add ability to used different font color or background color for specific MARC tags in Advanced Editor
by bugzilla-daemon＠bugs.koha-community.org 06 May '21

06 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26373 Bug ID: 26373 Summary: Add ability to used different font color or background color for specific MARC tags in Advanced Editor Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In the Advanced Editor it would be helpful to be able to to highlight (a different font color, a background color, etc.) specific MARC tags so info in those tags is easily seen during cataloging. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 21212] New: Syndetics image size should be configurable
by bugzilla-daemon＠bugs.koha-community.org 06 May '21

06 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21212 Bug ID: 21212 Summary: Syndetics image size should be configurable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Syndetics offers different image sizes - results currently use the small size which can appear low res and ugly on some browsers. There should be a configuration option for the library to choose size -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 26925] New: Pickup library list should be in alphabetical order
by bugzilla-daemon＠bugs.koha-community.org 05 May '21

05 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26925 Bug ID: 26925 Summary: Pickup library list should be in alphabetical order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 When we fetch the list of valid pickup locations for placing a hold on the staff client, we grab a separate list of valid locations for each item on that bib, put each of those sub-lists in alphabetical order, and then string them together. We need to alphabetize the entire list at the end. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 24852] New: XSLT paths not adjusted for dev installs
by bugzilla-daemon＠bugs.koha-community.org 05 May '21

05 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24852 Bug ID: 24852 Summary: XSLT paths not adjusted for dev installs Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org We are building the XSLT paths with intrahtdocs, it should be intranetdir (and assume that have the usual git structure) -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 26364] New: XISBN.t makes a bad assumption about return values
by bugzilla-daemon＠bugs.koha-community.org 04 May '21

04 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26364 Bug ID: 26364 Summary: XISBN.t makes a bad assumption about return values Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org 75 eval { $results_thingisbn = C4::XISBN::get_xisbns($isbn1,$biblionumber3); }; 76 SKIP: { 77 skip "Problem retrieving ThingISBN", 1 78 unless $@ eq ''; 79 is( $results_thingisbn->[0]->{biblionumber}, 80 undef, 81 "Doesn't get biblionumber if the biblionumber matches the one passed to the sub." ); 82 } Here we are testing that we don't get the same book that we passed into the sub in the list that is returned, however, we shouldn't assume that we get nothing, we should just check that it is not the biblionumber we passed in -- You are receiving this mail because: You are watching all bug changes.

1 38

[Bug 27784] New: Unknown authority types break elasticsearch authorities indexing
by bugzilla-daemon＠bugs.koha-community.org 03 May '21

03 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27784 Bug ID: 27784 Summary: Unknown authority types break elasticsearch authorities indexing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com We are seeing more libraries ending up with 'SUBDIV' type authority records in their systems. Koha has no support for these. They can be added to the authority types in the staff interface, however, values are hardcoded in various modules and Koha has no concept of how to link a subfield heading to a record, we only deal in whole fields The larger problem is something to think about, but more directly we should not allow indexing to die when an unknown type is encountered To recreate: 1 - Import a subdivision authority record via Z39 or use the one attached to this bug 2 - perl misc/search_tools/rebuild_elasticsearch.pl -v -d 3 - Authority indexing dies: Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. Use of uninitialized value $tag in regexp compilation at /usr/share/perl5/MARC/Record.pm line 206. Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 207. Can't call method "tag" on an undefined value at /kohadevbox/koha/C4/Heading.pm line 71. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 27316] New: In mappings use yes/no for sortable
by bugzilla-daemon＠bugs.koha-community.org 03 May '21

03 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27316 Bug ID: 27316 Summary: In mappings use yes/no for sortable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com In search engine configuration (Elasticsearch), there is a colum 'sortable'. It contains 'Undef', 0 or 1. 0 and 1 are not really friendly values for a boolean. And also the translation seems to replace 0 by empty string (seen in fr-FR translation). I propose to replace by Yes/No like other boolean. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 20589] New: Add field boosting and use elastic query fields parameter instead of depricated _all
by bugzilla-daemon＠bugs.koha-community.org 03 May '21

03 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20589 Bug ID: 20589 Summary: Add field boosting and use elastic query fields parameter instead of depricated _all 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: glasklas(a)gmail.com Generate a list of fields for the query_string query fields parameter, with possible boosts, instead of using "_all"-field. Also add "search" flag in search_marc_to_field table so that certain mappings can be excluded from searches. Add option to include/exclude fields in query_string "fields" parameter depending on searching in OPAC or staff client. Refactor code to remove all other dependencies on "_all"-field. (the atomicupdate sql-file is a bit obfuscated since had to be able to run in multiple time without error because of our local deploy-script, when moving this all procedure related code can be removed, only the "ALTER TABLE.."-lines are relevant.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 102

[Bug 25325] New: ElasticSearch mapping export lacks staff_client/opac fields
by bugzilla-daemon＠bugs.koha-community.org 03 May '21

03 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25325 Bug ID: 25325 Summary: ElasticSearch mapping export lacks staff_client/opac fields 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: frederic(a)tamil.fr export_elasticsearch_mappings.pl doesn't export staff_client and opac fields. Its means that when reimporting (Reset mapping in Search engine configuration) indexing rules, the searchability (staff/opac) of fields will be lost. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30