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

[Bug 25631] New: Adding ability to alter the expiration date of the hold from the Patron's Account
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '23

03 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25631 Bug ID: 25631 Summary: Adding ability to alter the expiration date of the hold from the Patron's Account 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently, for a hold expiration date to be changed, it would need to happen from the Item's Record (Hold), or the patron themselves can edit/add an expiration date. It would be nice to be able to add/edit an expiration date to the patron's hold from their Holds Summary on the Patron detail page. members/moremember.pl circ/circulation.pl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 27311] New: Don't pass borrowernumber to check_password plugin hook
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '23

03 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27311 Bug ID: 27311 Summary: Don't pass borrowernumber to check_password plugin hook Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org check_password is implemented in two places: 1. In Koha::Patron::set_password https://git.koha-community.org/Koha-community/Koha/src/branch/master/Koha/P… 2. In Koha::Patron::store https://git.koha-community.org/Koha-community/Koha/src/branch/master/Koha/P… The call to the plugin inside Koha::Patron::store comes before this line: $self = $self->SUPER::store; which means there is not yet a borrowernumber to pass to the plugin, and this never worked. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 26247] New: Search terms retained in header search creates system inconsistency
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '23

03 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26247 Bug ID: 26247 Summary: Search terms retained in header search creates system inconsistency Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If you type "test" in "Search the catalog" and click "Submit", the search term will be retained in the box. This means if you do a search and then want to scan a barcode into "Check out", "Check in", or "Renew", you first have to manually clear the search terms. This is inconsistent with how the header search boxes work overall. For instance, if you do a "Check out", it doesn't retain the value used to search. Either the search terms shouldn't be retained after a catalog search (change introduced in Bug 19046), or the text shouldn't be copied from that tab to other tabs. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 75

[Bug 29415] New: Wrong number of received items/quantity shown in several places
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '23

03 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29415 Bug ID: 29415 Summary: Wrong number of received items/quantity shown in several places 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org For standing orders there is something not correct with the way the number of items received is calculated. A Order 1) Create a basket as standing order 2) Create an order for any record in your catalog 3) Verify quantity is 1 (always for standing orders) B Receive 1) Receive shipment for your order 2) Make sure to change quantity received to something higher than 1 3) Finish receiving C Verify display 1) Search for your invoice on the invoices page 2) Verify it shows quantity received as entered 3) Got to invoice details page /cgi-bin/koha/acqui/invoice.pl?invoiceid=1 4) Verify it still shows 1 as quantity - should show the received quantity 5) Click on the record's title to go to the detail page 6) Switch to acquistion detail tab 7) Verify it shows 1 too - should differentiate between ordered/received I think the first (invoice) is clearly a bug, the second might be seen as a display error, but we should specify which quantity is shown and possibly add a display for ordered / received. If the status is received the info on the acq tab is definitely misleading. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 28611] New: Incorrect Select2 width
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '23

03 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28611 Bug ID: 28611 Summary: Incorrect Select2 width Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Cataloging Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The width picked by Select2 is not correct, the longest option's size is used but: * it is sometimes split on two lines * the close button hides the end of the value https://snipboard.io/v4P7HN.jpg -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 27325] New: Fix singular/plural forms on the OPAC dashboard
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '23

03 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27325 Bug ID: 27325 Summary: Fix singular/plural forms on the OPAC dashboard Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 26123 At the moment the dashboard panel on the OPAC start page uses "checkout(s)", "overdue(s)", "hold(s)" etc. We have the tools now to deal with these in a nicer way, showing "1 hold" and "2 holds" and deal with these nicely in translations as well. For documentation see: https://wiki.koha-community.org/wiki/Internationalization,_plural_forms,_co… For an example see the result list on the staff side: https://git.koha-community.org/Koha-community/Koha/src/branch/master/koha-t… [% tnx('{count} item', '{count} items', SEARCH_RESULT.items_count, {count = SEARCH_RESULT.items_count}) | html %] Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26123 [Bug 26123] Show info about existing OPAC note/Patron message on patron's dashboard -- You are receiving this mail because: You are watching all bug changes.

1 23

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