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

[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 27739] New: Advanced editor should use DefaultCountryField008 system preference rather than hardcoding xxu
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27739 Bug ID: 27739 Summary: Advanced editor should use DefaultCountryField008 system preference rather than hardcoding xxu Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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: m.de.rooy(a)rijksmuseum.nl Depends on: 27738 cateditor-widgets-marc21.inc uses DefaultLanguageField008 for the initial value of the language in 008/35-37, but just hardcodes xxu rather than using the companion pref DefaultCountryField008 for 008/15-17. Since using the pref requires a fallback when it's unset, and bug 27738 proposes changing the current fallback in the basic editor, this bug should wait on an outcome there before being fixed. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27738 [Bug 27738] Set fallback for unset DefaultCountryField008 to |||, "no attempt to code" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 27726] New: OPACProblemReports cuts off message text
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27726 Bug ID: 27726 Summary: OPACProblemReports cuts off message text Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hannah.co(a)northwestu.edu QA Contact: testopia(a)bugs.koha-community.org OPACProblemReport text is truncated to 255 characters, in both database and email. I tested and confirmed that the patron-facing form does not limit the amount of text entered, at least not before more than 500 characters. The form should either limit characters and warn patrons of the character limit, or the database field should be expanded to allow more data storage. -- You are receiving this mail because: You are watching all bug changes.

1 32

[Bug 27738] New: Fix fallback for unset DefaultCountryField008 system preference
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27738 Bug ID: 27738 Summary: Fix fallback for unset DefaultCountryField008 system preference 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: m.de.rooy(a)rijksmuseum.nl Depends on: 13912 Bug 13912 added DefaultCountryField008 to allow defaulting the place of publication to something other than the previous default of xxu ("somewhere in the United States, but I don't know what state"). Trying to follow the Koha Way of never changing existing behavior, only adding a preference to fix it, it intended to fall back to xxu, but https://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=cataloguing/valu… thought the preference would be undefined if it wasn't set, and then a QA followup updated the DB to add it so it's always defined, and the // "xxu" is unreached and the default value of the pref, '', gets space-padded to three characters long, ' '. Since we've now gone 3.3 years with the default having switched from the unfortunate choice of 'xxu' to the invalid ' ' without anyone filing a bug about it, I assert that the Koha Way is wrong in this case, that nobody actually wanted to retain the behavior of defaulting to saying that every book was published in an unknown US state (or if they did exist, they already fixed it by using that as their DefaultCountryField008), and we can fix the bug of defaulting to an invalid value by choosing a new default when DefaultCountryField008 isn't set, the value "|||" which is "no attempt to code" which is precisely the case when the cataloger doesn't change it and the system adminstrator doesn't say it should have a particular value whether or not that value is correct. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13912 [Bug 13912] Add syspref for default place of publication (country code) for field 008, range 15-17 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 26459] New: Allow sip_cli_emulator to handle cancelling holds
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26459 Bug ID: 26459 Summary: Allow sip_cli_emulator to handle cancelling holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 27748] New: Encoding problem in link to OverDrive results
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27748 Bug ID: 27748 Summary: Encoding problem in link to OverDrive results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org If you have OverDrive enabled and do a search in the OPAC, you get a link that says e.g. "Found 1 results in the library's OverDrive collection". But if you search contains non-ASCII characters, the search goes wrong. Example: Do a search for "göteborg": https://kohaopac.alingsas.se/cgi-bin/koha/opac-search.pl?q=g%C3%B6teborg (The URL shows the query as q=göteborg, but when I paste it here it is turned into q=g%C3%B6teborg.) The link says: Found 4 results in the library's OverDrive collection The actual link is: https://kohaopac.alingsas.se/cgi-bin/koha/opac-overdrive-search.pl?q=g%F6te… If you foloow that link you get to this page: https://kohaopac.alingsas.se/cgi-bin/koha/opac-overdrive-search.pl?q=g%F6te… which says "OverDrive search for 'g�teborg'" and shows 53 results, because the query was cut off at the "ö", and a search was actually made for just the letter "g" (whatever comes before the first non-ascii-char). If I change the encoding in the link from: https://kohaopac.alingsas.se/cgi-bin/koha/opac-overdrive-search.pl?q=g%F6te… to: https://kohaopac.alingsas.se/cgi-bin/koha/opac-overdrive-search.pl?q=g%C3%B… or https://kohaopac.alingsas.se/cgi-bin/koha/opac-overdrive-search.pl?q=götebo… the page shows 4 results, as promised. -- You are receiving this mail because: You are watching all bug changes.

1 18