- Koha - lists.katipo.co.nz

Call for news - Newsletter December 2020
by Michael Kuhn 13 Dec '20

13 Dec '20

Hi I'm collecting news for the December 2020 Koha Community Newsletter. Please send anything noteworthy to: kohanews (at) gmail (dot) com News criteria: * News items can be of any length. * Images are fine. * Anything and everything Koha. * Submit by the 26th of the month. For events: * Please include dates for past events. If I can't find dates I may not add it. * Announcements for future events with dates to be announced are fine, e. g. Kohacon. * For past events, one month back is the cut-off. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. Thank you! Michael Kuhn Editor, Koha Community Newsletter

1 0

Call for news - Newsletter December 2020
by Koha Community Newsletter 13 Dec '20

13 Dec '20

Hi I'm collecting news for the December 2020 Koha Community Newsletter. Please send anything noteworthy to: kohanews (at) gmail (dot) com News criteria: * News items can be of any length. * Images are fine. * Anything and everything Koha. * Submit by the 26th of the month. For events: * Please include dates for past events. If I can't find dates I may not add it. * Announcements for future events with dates to be announced are fine, e. g. Kohacon. * For past events, one month back is the cut-off. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. Thank you! Michael Kuhn Editor, Koha Community Newsletter

1 0

Red Hat 8, installing dependencies
by Bales (US), Tasha R 12 Dec '20

12 Dec '20

Good afternoon, I'm trying to install the latest version of Koha on Red Hat 8.1, using the Koha Wiki instructions<https://wiki.koha-community.org/wiki/Koha_on_Redhat_Enterprise_6> for Red Hat 6. Perhaps you can help with a couple questions. First, the Wiki contains a list of about 70 dependencies that should be installed before Koha. Since the Wiki article is dated, is there a method for determining whether this list is still accurate for Red Hat 8 and current Koha? Or, would one just need to be on the lookout for inevitable errors and complaints about missing dependencies? Next, I'm limited to working with a corporate repository-I cannot connect to the internet--but I was able to install all but 11 of the recommended packages, see below. I don't necessarily know that all of these are critical requirements, but some of them seem significant when I Googled them for more info. They are as follows: * cloog-ppl * ghostscript-devel (I have the non-devel package) * gnome-utils-libs (I don't think we need this) * ImageMagick * ImageMagick-devel * Imake (May not need this) * jasper-devel (We have jasper-libs) * lcms-devel * libXdmcp-devel * libxml2-python * ppl If you can advise where I ought to look to gain an understanding of whether these missing packages are 1) true requirements for Koha 20.x, given I obtained them from an older Wiki article; 2) show-stoppers that will prevent using Koha, or certain features of Koha, if they are not present. I appreciate and thank you in advance for any advice you may have. I am doing a good amount of research on the web to try to answer my own questions, but I'm a bit out of my league. Thanks for your time and consideration, Tasha R. Bales

2 2

Advice for hardware/technical requirements for cloud implementation
by Bales (US), Tasha R 12 Dec '20

12 Dec '20

Good morning, I'd like to ask for suggestions about hardware recommendations for installing Koha. We have about 1.5 million bibliographic records. Perhaps the reason we're not seeing a lot of info is just that Koha/MySQL/Zebra is relatively lightweight? I've done some Googling and quite a bit of inspection of the Wiki and documentation, but haven't found anything specific. I'm an applications admin and don't deal with installing and provisioning servers, so pardon my ignorance. I'm anticipating questions from IT-we anticipate hosting in our own cloud, on Ubuntu-and want to be prepared. We don't plan on uploading files to any bib records, if that's relevant. Thanks in advance for any words of wisdom, Tasha R. Bales

2 1

Authority controlled fields for publisher
by Peter Korsten 11 Dec '20

11 Dec '20

Hi, The topic has been asked before, but not exactly in the specific circumstances that I'm facing. My company (essentially, yours truly) is installing Koha for a customer, and migrating data. They insist on having fields 260$a and 260$b to be authority controlled. I solved that by modifying the BKS framework, setting 260$a to be a GEOGR_NAME and 260$b a CORPO_NAME. So far, so good. The trouble starts when you try the little icon to look up an authority record. If I click on that icon for 260$b (name of the publisher) and choose an existing one, the value instead ends up in 260$a. Now I don't think that this is a bug in Koha, but I do think that I'm not understanding this facility entirely, and the documentation doesn't seem to address this issue either. I'm aware that field 260 is supposed to contain transcribed data, and we've pointed this out to the customer, but this is what they want. Could somebody please enlighten me, whether I've taken the correct approach? Thanks, - Peter

3 2

some staff users cannot access the OPAC
by Isabel Pineda 11 Dec '20

11 Dec '20

Hi. We have got a strange problem with some of our staff users: They can access the intranet but for some reason they cannot access the OPAC. I have already tried several things - changing the password in the administration form, changing the password through the "Forgot password" process in the OPAC for example - but they still cannot log in the OPAC. Does anybody have an idea why that might be? If there is nothing that can be done, I will delete and recreate these users and hope that it works this time. I am just curious about the reason, because for most staff users it is working without a problem. Thank you very much Isabel Pineda

3 5

Koha 20.11 + ES 6 - Opac Browse Search with ES - "An error occurred, please try again."
by Craig Butosi 11 Dec '20

11 Dec '20

Hi all, Running 20.11 on Ubuntu 18.04 with ES 6.x. I've successfully upgraded to 20.11 (congrats to everyone involved, btw!). One hiccup. The Browse Search module available for ES users is throwing an error on /opac-browse.pl. 1. The error reads "An error occurred, please try again." 2. It is persistent (user sees it before running a search and upon landing on the page) 3. After attempting to search on a basic query, nothing happens 4. Browse Search was working perfectly for me in Koha 20.05 + ES 5.x You can view the error here: https://library.craigbutosi.ca/cgi-bin/koha/opac-browse.pl Has anyone experienced this before? Can anyone advise? Many thanks, Craig Butosi, MA, MLIS, B Mus (Hons) Library: library.craigbutosi.ca

2 1

Re: [Koha] Koha Digest, Vol 182, Issue 10
by dcook＠prosentient.com.au 11 Dec '20

11 Dec '20

Hi Peter, Without rewriting the Koha code, it's impossible to authority control 2 subfields in a field. There's a few reasons why. First, there is only one "9" subfield available for the linkage to the authority record. Second, Koha is hard-coded to authority control only the "a" subfield. I have gotten it to work with the 260$b but only if there is no authority control on 260$a. Ultimately, it can't really done without rewriting some core parts of Koha. My suggestion would be to use "Authorized Value Lists" instead of authorities for the 260$a and 260$b instead, although I imagine that the customer won't like that. Someone else might have other ideas but that's my 2 cents. David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- Date: Thu, 10 Dec 2020 00:16:32 +0100 From: Peter Korsten <pkpublic(a)severity-one.com> To: koha <koha(a)lists.katipo.co.nz> Subject: [Koha] Authority controlled fields for publisher Message-ID: <CAML7JVGh+8L0EEG7cqvAjhS=JRsRbgMozSAGvfGAQwpqQvuRbg(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Hi, The topic has been asked before, but not exactly in the specific circumstances that I'm facing. My company (essentially, yours truly) is installing Koha for a customer, and migrating data. They insist on having fields 260$a and 260$b to be authority controlled. I solved that by modifying the BKS framework, setting 260$a to be a GEOGR_NAME and 260$b a CORPO_NAME. So far, so good. The trouble starts when you try the little icon to look up an authority record. If I click on that icon for 260$b (name of the publisher) and choose an existing one, the value instead ends up in 260$a. Now I don't think that this is a bug in Koha, but I do think that I'm not understanding this facility entirely, and the documentation doesn't seem to address this issue either. I'm aware that field 260 is supposed to contain transcribed data, and we've pointed this out to the customer, but this is what they want. Could somebody please enlighten me, whether I've taken the correct approach? Thanks, - Peter

1 0

Indexing 100$q, 600$q, 700$q
by Charles Kelley 10 Dec '20

10 Dec '20

Hi, all! Over half of the authors in my library's collection have names in non-Roman writing systems, e.g., CJK and Cyrillic. We are entering the names in the bibliographic records in the current RDA pairing of 1XX-880, e.g., 100 1_ $6 880-01 $a Tanaka, Nobuo 880 1_ $6 100-01 $a 田中信男 This works well in searching. However, when there is a subfield q, searching by the version in subfield q fails. For example, if we search for a work by this author, 100 1_ $6 880-01 $a Tanaka, Nobuo 880 1_ $6 100-01/[dollar]1 $a 田中信男 $q (たなのぶお) searching by Tanaka, Nobuo and 田中信男 finds works by him, but searching by たなのぶお finds nothing. I suppose we can put the hiragana in parentheses in 880$a, e.g., 100 1_ $6 880-01 $a Tanaka, Nobuo 880 1_ $6 100-01/[dollar]1 $a 田中信男 (たなのぶお) but I'm trying to avoid straying too much from the current cataloging standards. If we have to stray, we will and call it the local standard. Moreover, I don't want to enter too many 700 author name variants for searching's sake because then it looks like there are three or more authors instead of just one or two. Example: 100 1_ $6 880-01 $a Tanaka, Nobuo 880 1_ $6 100-01/[dollar]1 $a 田中信男 $q (たなのぶお) 700 1_ $6 880-02/[dollar]1 $a 田中信男 $q (たなのぶお) 880 1_ $6 700-02/[dollar]1 $a たなのぶお This is a long winded way to ask whether it's possible to index $q in the 100, 600, and 700 fields? System Koha 20.05 Debian 9 "Stretch" ElasticSearch is installed. Thanks for your help, everyone! -- 気を付けて。 /ki wo tukete/ = Take care. -- Charles. Charles Kelley, MLS PSC 704 Box 1029 APO AP 96338 Charles Kelley Tsukimino 1-Chome 5-2 Tsukimino Gaadenia #210 Yamato-shi, Kanagawa-ken 〒242-0002 JAPAN +1-301-741-7122 [US cell] +81-80-4356-2178 [JPN cell] mnogojazyk(a)aol.com [h] cmkelleymls(a)gmail.com [p] linkedin.com/in/cmkelleymls <http://www.linkedin.com/in/cmkelleymls> Meeting Your Information Needs. Virtually.

1 0

Re: [Koha] Recursive error in 403.pl redirects
by Jonathan Druart 10 Dec '20

10 Dec '20

Did you remove your changes to see if they caused the AH00122?

1 0