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

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

21.05 and release-notes-needed workflow
by Jonathan Druart 11 Dec '20

11 Dec '20

Hi devs, There is a small adjustment about the "release-notes-needed" bugzilla keyword for 21.05. With the documentation team we decided that the "Text to go in the release notes" field must be filled *before* the new enhancements and features are pushed to master. If you have patches that reach the "Passed QA" status and that the bug report does not have release notes, I will add the "release-notes-needed". The patches won't be reviewed and pushed until release notes have been correctly added. The point of this workflow is 1. to make sure we won't have new enhancement/ft without release notes when the major release is done, 2. help the documentation team to write the manual and 3. introduce the habit to write the release notes when the patches are submitted, to help testers, QAers and RM. Let us know if you have any questions! Cheers, Jonathan

1 0

purchasing GoDaddy Servers
by Anthony Snell 10 Dec '20

10 Dec '20

These is some strange information I got from GoDaddy today they have current customers on certain servers to that CAN'T be upgrade to the newer versions of Ubuntu and require users to purchase new servers to host Koha on!!! [Anthony Snell]

1 0

The logic of BiblioAddsAuthorities and AutoCreateAuthorities...
by dcook＠prosentient.com.au 07 Dec '20

07 Dec '20

Hi all, Here's the current state of BiblioAddsAuthorities and AutoCreateAuthorities: 1. You can manually input text into an authority controlled field if BiblioAddsAuthorities is enabled. 2. Automatic linking between bib records and authority records *only* happens if BiblioAddsAuthorities is enabled. 3. AutoCreateAuthorities will automatically generate authorities if BiblioAddsAuthorities is enabled. I think that this all makes sense when manually inputting records, but it doesn't make sense when you're using automation like Z39.50, Staged MARC Upload, or other bulk tools. In those cases, you might want automatic linking between bibs and authorities (with or without automatic authority creation), but you might still want authority controlled fields to be read-only when manually working with records. I am wondering if anyone else has any insight into this. In my mind, BiblioAddsAuthorities should probably be "BiblioAddsAuthorities" and "BiblioAutolinkAuthorities". Or maybe the "read-only" flag could be on MARC frameworks... I'm waiting to see what some librarians say, but keen to gather ideas. 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

1 0

koha-zebra --stop doesn't work?
by dcook＠prosentient.com.au 04 Dec '20

04 Dec '20

Hi all, Is it just me or does "koha-zebra --stop" not actually stop Zebra? David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

3 5

Thoughts on Search Syntax (Zebra but maybe Elasticsearch)
by dcook＠prosentient.com.au 03 Dec '20

03 Dec '20

Hi all, I ran into a problem today where the search query 'Emperor penguin (Aptenodytes forsteri) foraging ecology' (without single quotes) was creating a "CCL parsing error" in Zebra. I had QueryAutoTruncate enabled so QueryWeightFields was automatically disabled. Solutions include: 1. Wrap the search query in double quotes a. "Emperor penguin (Aptenodytes forsteri) foraging ecology" 2. Escape the parentheses with a backslash a. Emperor penguin \(Aptenodytes forsteri\) foraging ecology 3. Turn off QueryAutoTruncate a. This lets the weighted query code thoroughly mangle the query which includes wrapping it in double quotes. b. Note though that this option also makes it so that a search wrapped in double quotes (like Solution 1) becomes a CCL parsing error I think many of us know that Koha's Zebra-based query building is terrible, but changing it obviously has consequences and we have so many different search preference permutations that it makes it difficult to regression test search changes. We could start showing users when they have searches with syntax errors. but then we all will probably start getting a lot of calls. Although I was thinking that when showing that there was a syntax error with their query, we could also provide a little "cheat sheet" with the basics of Zebra's CCL syntax. (Of course, that's really only relevant when we're passing queries straight through to Zebra and not butchering them first in Koha.) We could try to fix search, but then who has the time/money for that? Why fix something that is not (seemingly) broken? I am wondering what other people think. Personally, I'm thinking that we should not allow complex queries in the OPAC "Search" box. We treat that box (as we always should have) as the operand to the index chosen in the "Library catalogue" drop down list. However. that would be a breaking change for anyone that has bookmarked any OPAC searches with complex search queries. I suppose that we could create a new System Preference like "SimplifySearch" and just enable that for new Koha installations though. Maybe one day we could then remove that system preference and just make it "The Way". After all, I think that the *majority* of people are going to be performing fairly straight forward searches in the OPAC "Search" box. They're not going to be doing things like '(kw,phr,rtrn:"David writes verbose emails") OR ( (ti,phr,ext:"I think David's ideas have some merit") AND (su:Emails) )'. Relevant bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27088 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27139 David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

Koha Plugin Hooks (Naming,etc)
by dcook＠prosentient.com.au 02 Dec '20

02 Dec '20

Hi all, I propose that new Koha Plugin Hooks start with a prefix of "hook_". If you look at https://wiki.koha-community.org/wiki/Koha_Plugin_Hooks or the Kitchen Sink plugin, it's impossible to tell what methods are "hooks" and what are part of the basic plugin core API. Also, if a hook is going to modify a template directly (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27114 and https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27120) I think we should probably come up with some agreements on how that's best to work, so we don't end up with N different approaches for the same intention. I think that https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890 raises some interesting issues about how it's not easy to modify Koha's HTML output using plugins. Perhaps we should have a little analysis of some key pages and identify hooks, or do something a bit more complex/comprehensive. (Of course, I already have too many other things I'm working on do a POC for this right now.) David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

Happy Advent
by Renvoize, Martin 01 Dec '20

01 Dec '20

Hi All, As a long term follower of the perl advent <http://www.perladvent.org/2020/> calendar series, it's been on my mind for a few years now to emulate it for the Koha world.. As such, I've badgered a few devs for a bit of help and low and behold.. I'm proud to announce our very own: https://koha-community.gitlab.io/KohaAdvent Many thanks to my "volunteers" helping to bring this together at the last minute and especially Tomas for writing the first article to get us underway. The theme will be plugins, integrations and api's from the perspective of development. Have a great xmas everyone, *Martin Renvoize, MPhys (Hons)* <https://www.ptfs-europe.com> Development Team Manager Community Release Manager (19.11, 20.05) *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvoize(a)ptfs-europe.com www.ptfs-europe.com Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info(a)ptfs-europe.com

2 1