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

[Bug 28048] New: Getting Internal Server Error while importing Patrons
by bugzilla-daemon＠bugs.koha-community.org 26 Apr '21

26 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28048 Bug ID: 28048 Summary: Getting Internal Server Error while importing Patrons Change sponsored?: --- Product: Koha Version: unspecified Hardware: HP OS: Linux Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: vermanite(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 118917 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=118917&action=e… Screenshot of error Getting Internal Server Error While importing patrons in .CSV format. This error occurs only when I am trying to import new patrons in CSV format. Server Details: OS: Ubuntu 16.04 LTS KOHA Version: 16.11.14.000 MySQL version: mysql Ver 14.14 Distrib 5.7.33 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 28023] New: Typo in Reply-To header
by bugzilla-daemon＠bugs.koha-community.org 26 Apr '21

26 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28023 Bug ID: 28023 Summary: Typo in Reply-To header Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Koha::Email has a typo for the Reply-To header! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 24940] New: Serials statistics wizard: order vendor list alphabetically
by bugzilla-daemon＠bugs.koha-community.org 26 Apr '21

26 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24940 Bug ID: 24940 Summary: Serials statistics wizard: order vendor list alphabetically Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Currently the vendor pull down in the serials statistics wizard appears to be ordered by vendor id instead of sorting alphabetically by vendor name. This is quite confusing for a longer list. To test: - Add at least 2 vendors: - First: Zzzz - Second: Aaaa - Add subscriptions for each of the vendors - Check the pull down in the serials statistics wizard - Verify it lists them as Zzzz, Aaaa -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 26312] New: Add some error handling during Elasticsearch indexing
by bugzilla-daemon＠bugs.koha-community.org 26 Apr '21

26 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26312 Bug ID: 26312 Summary: Add some error handling during Elasticsearch indexing 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: nick(a)bywatersolutions.com Currently Elasticsearch dies if we get an error rather than a response from the ES Client. Generally we can see something like [6056] Committing 5000 records... [Timeout] ** [http://XXX.XXX.XXX.XXX:9200]-[599] Could not write to socket: 'Connection timed out', called from sub Search::Elasticsearch::Role::Client::Direct::__ANON__ at /usr/share/koha/lib/Koha/SearchEngine/Elasticsearch/Indexer.pm line 123. With vars: {' Rather than killing the whole indexing process, we should catch the error, fail the commit, and keep indexing records. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 55

[Bug 26679] New: Elasticsearch and Genre/Form Terms: "No results found" after clicking genre term URL in opac-detail
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26679 Bug ID: 26679 Summary: Elasticsearch and Genre/Form Terms: "No results found" after clicking genre term URL in opac-detail Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbutosi(a)gmail.com Koha 20.05.04.000 w/ ES 5.x.x. Ubuntu 18.04 MariaDB Problem: After running a keyword search, clicking on a genre/form term URL from within opac-detail returns no results on that term, despite having records with the same gf term in the repository. Example: I have 4 bib records in my repository with a genre/form term "Star wars fiction": 1. Keyword search using "index-term-genre:Star wars fiction" returns 4 records. 2. keyword search using phrase "Star wars fiction" with quotes returns 4 records. 3. Subject search using "Star wars fiction" without quotes returns *no results*. 4. Clicking on genre term URL "Star wars fiction" within one of the 4 bib records on opac-detail screen returns *no results*. I was expecting that nos. 3 and 4 above would return 4 records, but doesn't. Is this an Elasticsearch problem, an ES configuration problem, an ES mapping problem, or XSLT problem? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 27201] New: New permission to modify pickup locations
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27201 Bug ID: 27201 Summary: New permission to modify pickup locations Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 18729, 27117 We need a new subpermission to allow modification of pickup locations. reserveforothers: modify_pickup_location Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18729 [Bug 18729] Librarian unable to update hold pickup library from patron pages without "modify_holds_priority" permission https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27117 [Bug 27117] Staff without modify_holds_priority permission can't update hold pick-up from biblio -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 27656] New: misc/cronjobs/longoverdue.pl better error message
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27656 Bug ID: 27656 Summary: misc/cronjobs/longoverdue.pl better error message Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz There are two ways of configuring misc/cronjobs/longoverdue.pl : use --lost arg or system preferences DefaultLongOverdueLostValue and DefaultLongOverdueDays. Actually if you don't use any of it, you get a message : "ERROR: No --lost (-l) option defined" Should also say something about preferences. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 26528] New: Koha return no result if there's invalid records in Z39.50/SRU server reply
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26528 Bug ID: 26528 Summary: Koha return no result if there's invalid records in Z39.50/SRU server reply Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: didier.gautheron(a)biblibre.com Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When searching for authorities if an authorities server reply has invalid records none are displayed. At least french BNF SRU server doesn't fully follow norm and can return an error confusing Koha protocol handler which then returns an empty MARC record. This patch silently removed bogus records. Test plan: 1- Add BNF SRU 2- Go to authorities page 3- Add an authority 4- Search for keyword(any) droits de l'homme 5- No result (Internal Server Error) 6- Apply patch 7- restart starman 8- redo 4 9- Many records are displayed -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 27529] New: Cannot place hold on OPAC if hold_fullfillment_policy is set to group and OPACAllowUserToChooseBranch not allowed
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27529 Bug ID: 27529 Summary: Cannot place hold on OPAC if hold_fullfillment_policy is set to group and OPACAllowUserToChooseBranch not allowed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests 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 In opac/opac-reserve.pl: 243 # When choosing a specific item, the default pickup library should be dictated by the default hold policy 244 if ( ! C4::Context->preference("OPACAllowUserToChooseBranch") && $itemNum ) { 245 my $item = Koha::Items->find( $itemNum ); 246 my $type = $item->effective_itemtype; 247 my $rule = GetBranchItemRule( $patron->branchcode, $type ); 248 if ( $rule->{hold_fulfillment_policy} eq 'any' ) { 249 $branch = $patron->branchcode; 250 } else { 251 my $policy = $rule->{hold_fulfillment_policy}; 252 $branch = $item->$policy; 253 } 254 } 255 $branch = $item->$policy; is problematic for group values To test: 1 - Set 'Default checkout, hold and return policy' -> 'Hold pickup library match' to item's hold group or patron's hold group 2 - Set OPACAllowUserToChooseBranch to 'Don't allow' 3 - Try to place an item level hold on the opac 4 - Ka-boom The method Koha::Item->patrongroup is not covered by tests! The method Koha::Item->itemgroup is not covered by tests! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 27979] New: Multiple item URIs break redirect if TrackClicks enabled
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27979 Bug ID: 27979 Summary: Multiple item URIs break redirect if TrackClicks enabled 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org You can add multiple URLs in the items.uri field by separating them with " | ". However if you also have the TrackClicks system preference enabled, the script is incorrectly verifying if the URL exists in the database. -- You are receiving this mail because: You are watching all bug changes.

1 17