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

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

01 Nov '23

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 3

[Bug 32396] New: CMS page default language link should still allow to the change language
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32396 Bug ID: 32396 Summary: CMS page default language link should still allow to the change language Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: pascal.uphaus(a)gwdg.de QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Test plan: 1. Install a second language to the koha instance 2. Enable the language via the systempreferences (language, OPAClanguages and opaclanguagesdisplay) 3. Adding a page via koha-domain/cgi-bin/koha/tools/additional-contents.pl?category=pages 4. added the translations default, english and the second language 5. Opening the default link for OPAC or for the Staff Interface 6. Change the Language and go back to the same url and reload the page. 7. Result: the language of the opac is still the default one Is this intended that the Link always resets the language to the default language, when accessing the page via link or go back and reload the page? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 34996] New: In Koha Patron List, add columns "sort1" and "sort2"
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34996 Bug ID: 34996 Summary: In Koha Patron List, add columns "sort1" and "sort2" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: eugenegf(a)yahoo.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently available columns for patron list are: checkbox, card, firstname, surname, address, category, library, expires_on and circ_notes. This enhancement request will hopefully add sort1 and sort2 in the patron list column. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 25051] New: Elasticsearch truncates range searches when QueryAutoTruncate is enabled
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25051 Bug ID: 25051 Summary: Elasticsearch truncates range searches when QueryAutoTruncate is enabled 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 To test: 1 - Enable QueryAutoTruncate 2 - Try a search like: copydate:[1990 TO 2010] 3 - Esplosions! Or at least, the search fails with error log like: [Request] ** [http://es:9200]-[400] [query_shard_exception] Failed to parse query [(copydate:[1990* TO* 2010])], with: {"index_uuid":"lYb_5AVrT7iyEgLK-TGewg","index":"koha_kohadev_biblios"}, called from sub Search::Elasticsearch::Role::Client::Direct::__ANON__ at /kohadevbox/koha/Koha/SearchEngine/Elasticsearch/Search.pm line 100. With vars: {'request' => {'path' => '/koha_kohadev_biblios/_search','mime_type' => 'application/json','serialize' => 'std','ignore' => [],'body' => {'query' => {'query_string' => {'fields' => ['cn-bib-source','number-legal-deposit','number-db','other-control-number','stock-number','ff7-00','cn-prefix','cn-class','local-classification','report-number','language-original','notforloan','number-natl-biblio','materials-specified','barcode','totalissues','arp','related-title','bio','index-term-genre','ff8-23','date-of-acquisition','number-govt-pub','title-series','identifier-publisher-for-music','pl','copydate','ctype','title-abbreviated','su-geo','host-item-number','author-in-order','ff7-02','title-uniform','identifier-other','cn-sort','ln-subtitle','author-name-corporate','personal-name','nlm-call-number','material-type','ccode','coden','name-geographic','itype','arl','restricted','copynumber','reading-grade-level','host-item','replacementprice','title-later','subject','isbn','title','title-other-variant','title-collective','stack','code-institution','name-and-title','ff8-29','corporate-name','cn-bib-sort','location','number-local-acquisition','homebranch','coded-location-qualifier','nal-call-number','ln-audio','author-name-personal','control-number','record-source','date-time-last-modified','extent','acqsource','bgf-number','related-periodical','interest-grade-level','interest-age-level','koha-auth-number','date-entered-on-file','holdingbranch','lc-card-number','curriculum','note','map-scale','author-personal-bibliography','abstract','bib-level','identifier-standard','ln','name','subject-name-personal','lost','withdrawn','itemtype','ta','editor','dewey-classification','uri','music-key','price','biblioitemnumber','itemnumber','provider','local-note','indexed-by','rtype','title-former','code-geographic','issues','classification-source','lc-call-number','replacementpricedate','record-control-number','cn-suffix','cross-reference','publisher','title-expanded','ff7-01','author','conference-name','contents','index-term-uncontrolled','datelastborrowed','thematic-number','local-number','datelastseen','reserves','not-onloan-count','title-key','title-cover','bnb-card-number','udc-classification','renewals','ff7-01-02','date-of-publication','lf','cn-item','dissertation-information','geographic-class','issn','damaged','author-title','lexile-number','llength','microform-generation'],'default_operator' => 'AND','query' => '(copydate:[1990* TO* 2010])','fuzziness' => 'auto','lenient' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),'analyze_wildcard' => $VAR1->{'request'}{'body'}{'query'}{'query_string'}{'lenient'}}},'size' => '20','from' => 0,'aggregations' => {'su-geo' => {'terms' => {'size' => '20','field' => 'su-geo__facet'}},'author' => {'terms' => {'field' => 'author__facet','size' => '20'}},'location' => {'terms' => {'field' => 'location__facet','size' => '20'}},'title-series' => {'terms' => {'size' => '20','field' => 'title-series__facet'}},'itype' => {'terms' => {'field' => 'itype__facet','size' => '20'}},'ccode' => {'terms' => {'field' => 'ccode__facet','size' => '20'}},'ln' => {'terms' => {'size' => '20','field' => 'ln__facet'}},'holdingbranch' => {'terms' => {'field' => 'holdingbranch__facet'}},'subject' => {'terms' => {'size' => '20','field' => 'subject__facet'}}}},'qs' => {},'method' => 'GET'},'body' => {'status' => 400,'error' => {'failed_shards' => [{'index' => 'koha_kohadev_biblios','reason' => {'index' => 'koha_kohadev_biblios','reason' => 'Failed to parse query [(copydate:[1990* TO* 2010])]','caused_by' => {'type' => 'parse_exception','reason' => 'Cannot parse \'(copydate:[1990* TO* 2010])\': Encountered " <RANGE_GOOP> "TO* "" at line 1, column 17. Was expecting: "TO" ... ','caused_by' => {'reason' => 'Encountered " <RANGE_GOOP> "TO* "" at line 1, column 17. Was expecting: "TO" ... ','type' => 'parse_exception'}},'type' => 'query_shard_exception','index_uuid' => 'lYb_5AVrT7iyEgLK-TGewg'},'shard' => 0,'node' => '-yc8mDy8SDu6U12yEpvXFA'}],'phase' => 'query','type' => 'search_phase_execution_exception','grouped' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),'reason' => 'all shards failed','root_cause' => [{'index_uuid' => 'lYb_5AVrT7iyEgLK-TGewg','type' => 'query_shard_exception','reason' => 'Failed to parse query [(copydate:[1990* TO* 2010])]','index' => 'koha_kohadev_biblios'}]}},'status_code' => 400} Use of uninitialized value $error in concatenation (.) or string at /kohadevbox/koha/catalogue/search.pl line 558. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 31112] New: Able to renew checkout when the number of holds exceeds available number of items
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31112 Bug ID: 31112 Summary: Able to renew checkout when the number of holds exceeds available number of items 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: joonas.kylmala(a)iki.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If AllowRenewalIfOtherItemsAvailable is set to Allow we are incorrectly (against the syspref description) allowing to renew some checkouts when the holds are coming from a single patron. When there is only 1 available item for checkout in the biblio and a single patron has made 2 biblio level holds we allow the patron who has a single item on loan to renew their item and disregard the fact the we are leaving one hold unfilled. According to the AllowRenewalIfOtherItemsAvailable syspref the renewal should only be possible when other items can fill all the unfilled holds. I have made a patch for this and will submit it shortly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 32657] New: neworderempty.pl should use RDA tag 264 not tag 260
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32657 Bug ID: 32657 Summary: neworderempty.pl should use RDA tag 264 not tag 260 Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: dch(a)interleaf.ie QA Contact: testopia(a)bugs.koha-community.org When SysPref 'UseACQFrameworkForBiblioRecords' is set to Don't use the framework 'ACQ' for bibliographic records fields, then publication details you enter to neworderempty.pl are inserted into tag 260 on the bibliographic record, but they should be inserted to tag 264 instead. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 34156] New: C4::Acquisition::FillWithDefaultValues handles leader incorrectly
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34156 Bug ID: 34156 Summary: C4::Acquisition::FillWithDefaultValues handles leader incorrectly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When adding to a basket from a new empty record, we call FillWithDefaultValues on the record from the form. In MARC::Record the leader is obtained via $record->leader But FillWithDefaultValues uses the tags form 'GetMarcStructure' where leader is 000 So when you add the record, we don't find a 000 and so add a field We end up with a record with the original leader, and a controlfield=000 with the default value. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 35146] New: Missing db_revs file for Koha 21.11.24
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35146 Bug ID: 35146 Summary: Missing db_revs file for Koha 21.11.24 Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org The Koha 21.11.24 minor point release is missing a db_revs file to increment the Koha version number in the database. https://git.koha-community.org/Koha-community/Koha/commit/df3374ec2f47c2de1… This means after upgrading to the 21.11.24 koha-common package on a server and upgrading the schema, Koha will still re-direct to the Koha web installer. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 33144] New: Authority lookup in advanced editor overencodes HTML
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33144 Bug ID: 33144 Summary: Authority lookup in advanced editor overencodes HTML Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart+koha(a)gmail.com, m.de.rooy(a)rijksmuseum.nl Depends on: 26102 Bug 26102 prevented XSS via malicious authority records (which would have been fun to exploit), but it did it by creating an HTML entity-encoded string and then handing it to a function which expected to get text, not HTML. As a result, if you look up the authority record for Simon & Schuster Audio (Firm) from the advanced editor, you wind up putting Simon & Schuster Audio (Firm) in your bib record. Steps to reproduce: 1. Set EnableAdvancedCatalogingEditor to Enable 2. Edit any Topical Term authority record, and at the end of 150 subfield a add (without the newlines, just offsetting it for easy copying) & Stuff </script><script>alert('boo ❤')</script> 3. Cataloging - Advanced Editor 4. Hit return in the editor to get a new line, type 650 and press tab three times, then Ctrl+Shift+L 5. Search for the authority you edited, click Choose Expected result: The editor should show 650 _ 4 ‡aAbduction & Stuff </script><script>alert('boo ❤')</script>‡vDrama. since that's the text of the authority you selected Actual result: The editor shows 650 _ 4 ‡aAbduction & Stuff </script> <script>alert('boo ❤');</script>‡vDrama. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26102 [Bug 26102] Javascript injection in intranet search -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 35200] New: Patron attributes should be translatable
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '23

31 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35200 Bug ID: 35200 Summary: Patron attributes should be translatable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N 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: frederic(a)tamil.fr I ran into this problem with a library that needed a lot of patron attributes, and they use self-registration. Their OPAC is in fr-CA, en, and es-ES. I created the patron attributes with labels in french. But then I had to write JQuery to translate them in en and es-ES. This is a sample of the js (I'm not a developer, so it might not be great, but it seems to work) $("html[lang='en'] body#opac-patron-registration a[name='patron-attr-start-1_NOM'] + li label").text("Baby's surname:"); $("html[lang='en'] body#opac-patron-registration a[name='patron-attr-start-2_DOSSIER'] + li label").text("Baby's file number:"); $("html[lang='es-ES'] body#opac-patron-registration a[name='patron-attr-start-1_NOM'] + li label").text("Apellido del bebe:"); $("html[lang='es-ES'] body#opac-patron-registration a[name='patron-attr-start-2_DOSSIER'] + li label").text("Número de expediente del bebé:"); I wonder if it would be possible to use the same process as translating the itemtypes (entry in localization table). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3