- Koha-devel - lists.koha-community.org

OpenURL Link Resolving on Koha
by Gene Stevenson 08 Mar '19

08 Mar '19

Koha family, We're in the midst of transitioning to Koha, but we're a non-traditional user. Instead of a library, we are an abstracting database working with Koha to make our service easier to use for our subscribers (mainly libraries). Think of us as a virtual library with our "patrons" being actual physical libraries. Each of our patrons need the capability of linking out from our database to their in-house full-text e-journal collections via OpenURL linking (link resolver). Do you all have ideas on how this might work? Thank you in advance for your time and consideration! Gene L. Stevenson, Executive Director Religious & Theological Abstracts 121 S. College St., Suite 106 Myerstown, PA 17067 USA Phone: (717) 866-6734 E-mail: <mailto:rtaed@rtabstracts.org> rtaed(a)rtabstracts.org URL: <http://www.rtabstracts.org/> www.rtabstracts.org

1 0

Critical bug fix to prevent data loss (Bug 22395)
by Nick Clemens 07 Mar '19

07 Mar '19

Hello all, It has been discovered there is a bug in the stable versions of Koha, 18.05.09 and 17.11.15 which can cause quoted text in records to be deleted upon edit/save https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22395 If you have not yet upgraded to the most recent maintenance release please wait a few days as we are releasing a new version to fix the issue. If you are running these versions please be aware of this bug and we will be sending a notice when the new versions are available. Thanks, Nick

2 2

Memcached problem with Koha
by Rémy DUCRY 07 Mar '19

07 Mar '19

Hello to all of you, I have a problem with Memcached that I am submitting to your expertise. I put you the link to the screenshot showing the server configuration: http://51.75.27.51/pref-sys.png , as you can see Memcached does not run when we have (normally) correctly configured it for. The server configuration: Koha Version 18.11.02.02.02.000 Ubuntu server version 18.04 Looking forward to your feedback, I wish you an excellent day.

2 1

Tags features
by Tomas Cohen Arazi 05 Mar '19

05 Mar '19

Hi all, while fixing issues with emojis in Tags (solved already in 21846, waiting from someone to stamp their QA signoff) I was told about 22420: tag cloud broken. Reverting the change from bug 14385 would 'fix it', meaning we restore the ability to properly scale tags based on their weight. I'm sending this email to clarify what is the expected behaviour that pretended to be introduced in 14385. It looks like it is trying to filter out those biblios that should be hidden in OPAC: cool. I can achieve this by decrementing the weights instead of what is done now. But then I noticed that the behaviour for logged in users is to display own tags only, and for anonymous users it displays all the tags? Can someone explain the desired behaviour so I don't make it worse while fixing the other problem? Thanks! -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F

2 2

Koha Community Newsletter: February 2019
by Koha Newsletter 03 Mar '19

03 Mar '19

Sorry for the delays on the news! Ran into some technical difficulties with Wordpress. Special thanks to Liz for the technical help! The Koha Community Newsletter for February 2019 is here: https://koha-community.org/koha-community-newsletter-february-2019/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email me with any corrections or suggestions. Chad Roseburg Koha Community Newsletter Editor

1 0

Koha community site Wordpress issue
by kohanews 03 Mar '19

03 Mar '19

The Wordpress site koha-community.org will not save my edits and I'm unable to publish. Anyone know who manages that? Thank you! -- Chad Roseburg Editor, Koha Community Newsletter

3 2

Re: [Koha-devel] [Koha] Barcode Troubles
by Mark Alexander 01 Mar '19

01 Mar '19

Excerpts from abrazier's message of 2019-02-28 15:50:51 -0700: > While editing items that are being > added to our collection, when we click in the field (p - Piece > designation (barcode)) which we have always had set to (autoBarcode: > generated in the form 1, 2, 3) we are no longer getting the barcode we > expect to see. > > We suspect it is now going back to barcodes that once belonged to items > that are now deleted (because, that earlier barcode is now available). I took a look at the Koha source code, and it seems that for some barcode types, it is using this SQL to determine where to start generating new barcodes: select max(abs(barcode)) from items; It then increments the value that it obtains this way to use as the new barcode. So I suspect that you could fix your problem by creating a dummy item that has the first barcode you want to use, minus one. Note that I am not an expert and have not tried this myself.

1 0

SSL problem with lists.koha-community.org
by David Cook 01 Mar '19

01 Mar '19

Hi all, It looks like BibLibre might be in charge of lists.koha-community.org? https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel seems to be sending an expired self-signed certificate with BibLibre information. Someone might want to take a look at that. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

2 1

Problems with "LOC" authorized values and tokenization
by David Cook 27 Feb '19

27 Feb '19

Hi all, I have a library with lots of problematic data in their "LOC" authorized value codes, and it's led me to a few issues. 1. LOC authorized values can contain "*", "(", and ")" but all of these characters will cause the ZOOM library to fail to compile the CCL2RPN query. 2. mc-loc (from the "Shelving location" tab on /cgi-bin/koha/catalogue/search.pl) seems to be doing an incomplete search. That means if you have two locations like "Big Box" and "Big Box - Drawer", "Big Box" will return items for both locations. The reason for #2 is actually kind of interesting. While the RPN/PQF query is "@attr 1=8013 @attr 4=1 apple_street" and @attr 4=1 represents a "phrase" search, Zebra is actually using the "w" register and not the "p" register. It's because of the "Completeness Attributes (type = 6)": "Incomplete subfield (1) is the default, and makes Zebra use register type="w", whereas Complete field (3) triggers search and scan in index type="p"." (https://software.indexdata.com/zebra/doc/querymodel-rpn.html) If we wanted to actually just get the exact location, we'd want to use "mc-loc,complete-field", but then we'd get Zebra errors because mc-loc doesn't use the "p" type register currently, although that would be easy enough to add. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

3 4

zebraidx with 1 large MARC file rather than many small MARC files
by David Cook 27 Feb '19

27 Feb '19

Hi all, I haven't looked into it too deeply, but I was curious if Zebra would have better performance indexing with 1 large MARC file versus many small MARC files. At the moment, we generate 1 huge MARC file and then pass that to zebraidx as an argument. Is that something we've always done or was it done as a performance enhancement? I haven't looked at the Zebra internals to see whether it reads the entire file into memory and then processes it or if it parses the XML using a stream reader. Zebraidx can also take a list of files from stdin*, but if you had tonnes of small files that could be troublesome. I suppose it doesn't matter too much as we march on to ElasticSearch, but I figure lots of people are using Zebra still and probably will for a long time, so perhaps worth thinking about. https://software.indexdata.com/zebra/doc/zebraidx.html David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

2 3