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

[Bug 18731] New: Orders table slow to load for vendors with many orders
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '21

28 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18731 Bug ID: 18731 Summary: Orders table slow to load for vendors with many orders Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some libraries may have hundreds of open orders for a vendor, depending on acqisitions workflow. At that number of open orders, the tables on parcel.pl take 10 to 20 seconds to load. To speed up the loading of this page and the data, we should convert the order tables from pre-loading all order data to ajax tables that load order data on an as needed basis. That way we are only pulling the data for the orders that are currently visible. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 111

[Bug 18755] New: Allow empty password fields in Patron Info requests
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '21

28 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18755 Bug ID: 18755 Summary: Allow empty password fields in Patron Info requests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Bug 16610 changed the behaviour of patron info requests and responses - previously if the password field was empty in the request, we returned password ok. Many sip clients assume that passing an empty pwd field means "I'm not validating a password - I just want to know patron is valid" and are failing because of the change in behaviour. As both scenarios are valid I suggest adding a parameter to the sip config to allow empty password fields to be treated as previously. To my knowledge this is only an issue in the patron info response. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[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