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

[Bug 32127] New: Always sort patrpn
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '23

02 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32127 Bug ID: 32127 Summary: Always sort patrpn Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 31

[Bug 31077] New: Return claims won't load on details tab, when ClaimReturnedLostValue is empty
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '23

02 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31077 Bug ID: 31077 Summary: Return claims won't load on details tab, when ClaimReturnedLostValue is empty Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When ClaimReturnedLostValue is empty, the tab with the number of open claims will show both on the checkouts and the details tab of the patron account in the staff interface, but on details, nothing will display when the tab is opened. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 19885] New: Allow MaxOpenSuggestions to be set by patron type
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19885 Bug ID: 19885 Summary: Allow MaxOpenSuggestions to be set by patron type Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be nice if we could set MaxOpenSuggestions by patron type/library. This would allow each library in a consortium to use the suggestions in the way that was most efficient for each library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[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 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 29750] New: Reserves.pm should check patron category hold policies when finding a reserve for an item
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '23

30 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29750 Bug ID: 29750 Summary: Reserves.pm should check patron category hold policies when finding a reserve for an item Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 23172 introduced a check for patron categories hold policies when the holds queue maps items to pending reserves. This patchset will introduce a check for patron categories hold policies when finding a reserve for an item. This is useful when the holds queue has not been generated. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 27236] New: Package PO translation files separately to koha-common
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '23

30 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27236 Bug ID: 27236 Summary: Package PO translation files separately to koha-common Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com I propose that we package PO translation files separately as "koha-i18n". This is a common practice in Debian: https://packages.debian.org/search?searchon=names&keywords=i18n As Bernardo pointed out in Bug 24211, ~350MB of Koha's installed size is just PO files. That's roughly 75% of Koha's installed size. Combined with Bernardo's early ideas from Bug 24211, we could actually package the PO files as compressed files (down from ~350MB to ~50MB). Libraries that need translations could make sure their vendors install koha-i18n (this is another use-case for koha-core vs koha-full), and then they can just decompress the languages required. Technically, this might even make it easier to provide updated translations when the only change in Koha is the translation (and no code/template changes). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 31029] New: ILL request ID in ILL history table should link to the ILL request if permissions allow for it
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '23

29 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31029 Bug ID: 31029 Summary: ILL request ID in ILL history table should link to the ILL request if permissions allow for it Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de When a patron has placed ILL requests, they are shown in the patron account in a new tab "ILL request history". >From this table, there is no way to get to the ILL request in the ILL module. We should link the request ID if the user has permissions to access the module. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3