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

Centralize and move to gitlab
by Jonathan Druart 08 Aug '18

08 Aug '18

Hi devs, (Spoiler: I am not talking about a move from bugzilla to gitlab for the Koha git repo) Just a quick comment: gitlab has the ability to move projects with all the issues. >From the export page of a project, they say: """ The following items will be exported: Project and wiki repositories Project uploads Project configuration including web hooks and services Issues with comments, merge requests with diffs and comments, labels, milestones, snippets, and other project entities """ So that will be easy to move (already discussed with Chris, will do in May) * koha-community-devs-users/kohadocs to koha-community/kohadocs * https://gitlab.com/koha-dashboard/koha-dashboard to koha-community/koha-dashboard And the ones from github too: * joubu/koha-misc4dev to koha-community/koha-misc4dev * Koha-Community/qa-test-tools to koha-community/qa-test-tools Then, maybe: koha-testing-docker koha-release-notes kohadevbox koha-howto The idea is to centralize our things in one place, ease the PRs and the ability to clone/fork keeping the visibility on what is the reference (account 'koha-community'). I would also like to generate a CI configuration for some of them. CI file for Koha: https://tree.taiga.io/project/joubu-koha-rm-1711/us/146 (I am going to submit that on bugzilla soon) CI file for the manual: https://gitlab.com/koha-community-devs-users/kohadocs/blob/master/.gitlab-c… Any pros/cons? Cheers, Jonathan (No troll please)

11 16

Exploration of Koha ElasticSearch implementation
by Claire Hernandez 06 Apr '18

06 Apr '18

Hi, I want to share a work with you. I knew we can now switch SearchEngine syspref to ElasticSearch in Koha community version, but I didn't know a lot more. I explored with some BibLibre guys what we can really do, if we can propose this feature to our users. It seems there is some work to do but it would be great to have a more solid version for 18.05 if we test and fix more things, a version for early adopters who want to try it in production. I began a document where I list the gap to this version, it is a work in progress. I integrated the items identified by Nick (kidclamp) in the wiki page (Elastisearch_status). Thanks. I could have put everything in bugzilla or wiki but it wasn't ideal to me at this time. Depending your feedback I can make it better. https://docs.google.com/spreadsheets/d/10VUKvIYZjlbJhE-oCLmInLe601su6vIRBRC… Notes about tabs: - Way to 18.05 : I wanted it "macro functionnal", but currently it lists features or issues that may be too small. I tried to evaluate the work in "complexity point", "1" can be one developper day or maybe more or less; - Questions : can be used as a faq, I dropped my questions, sometimes I answered myself and other time someone else answeredme; - Queries and behaviours : we did a lot of work to implement Solr in Koha (at BibLibre, it begun in 2011) and an advanced search version is always maintained. I think it can be asked, so I pasted a list of queries we work with, it is expected to be different, it is just examples; - Pros : quick list of advantages for ElasticSearch in Koha Please, feel free to read, add lines, add questions or whatever. I am often available on #koha (@clrh). Claire.

2 2

Write good bug report titles and commit messages
by Jonathan Druart 04 Apr '18

04 Apr '18

Hi devs, I would like to do a little reminder about the bug report titles and commit messages. For bugs: The bug report title must shortly tell what the *bug* is, whereas the commit messages must tell what the *fix* does. Sometimes they are not related at all. For instance: - bug report titles: "Feature X is not working correctly when Y is enabled", "Click on button 'Save' does not save the record", "Saving stuff on screen X does not work", "This script generates error logs", "Mystake is misspelled in this script", "Behaviour X no longer work as expected" etc. - commit messages: "Fix Feature X when Y is enabled", "Make sure behaviour is correct when button is clicked", "Remove warnings from this script", "Correct spelling of mistake in this script", "Fix regression on behaviour X" etc. For enhancements / new feature: We could have the same title and commit messages in some cases. - bug report titles: "Add new awesome feature", "Add the ability to do that", "Code is duplicated in method Koha::Stuff->method" - commit messages: "Add new awesome feature", "Add the ability to do that", "Remove code duplication in method Koha::Stuff->method" Note that "Address comment #42" is a terrible commit message. Then, I would like to standardize the commit messages a bit. We have "Bug 12345 - ", "Bug 12345: ", "Bug 12345" and "[follow-up]", "(follow-up)", "[QA Followup]", etc. I would suggest: "Bug 12345: you commit message" And reject any commit messages with only "follow-up" (or whatever how it is written), but accept "Bug 12345: (follow-up) same commit message as before" If you forgot something, even if "Bug 12345: (follow-up) This was missing" And QA follow-ups (added by QA team member): "Bug 12345: "(QA follow-up) Add/remove this stuff" I am going to suggest these change during the next dev meetings. If accepted I will change the bug report titles and commit messages before the push during few weeks, then ask authors to do it themselves (patches from new contributors will not be rejected for that reason). You should also read or re-read: https://wiki.koha-community.org/wiki/Bug_Reporting_Guidelines https://wiki.koha-community.org/wiki/Commit_messages Cheers, Jonathan

6 6

Plack only
by Tomas Cohen Arazi 20 Mar '18

20 Mar '18

I would like to know if you think there's any reason to keep the CGI mode as default in Koha deployments. I think we should make Plack the default. There are some issues, tough. But if we set that goal, we could focus on fixing them. What do you think? -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

8 22

REST API authentication for external clients
by Julian Maurice 02 Mar '18

02 Mar '18

Hi all, As you may know [1], BibLibre is working on an interface between Koha and Coral. To achieve that, Coral uses the Koha REST API. But we are facing a problem that is becoming really blocking : the lack of a proper authentication system for the REST API. At the moment, the only way to authenticate to the API is based on cookies. It works well for client-side javascript inside Koha, but it's not really usable by external clients. Is there someone here who use this API outside of Koha ? If so, how do you authenticate to it ? I think we really need an authentication mechanism other than cookies, so people can actually start using the API. There is bug 13920 [2] that hasn't moved since 8 months. I remember that some people disagreed with this patchset because it is crafting a custom authentication system instead of using some "standard" one (I remember OAuth was mentioned). Do you know of any "standard" auth system that we can implement, or existing Perl libraries we can use ? [1]: http://lists.koha-community.org/pipermail/koha-devel/2017-January/043430.ht… [2]: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13920 -- Julian Maurice <julian.maurice(a)biblibre.com> BibLibre

4 4

Bugs needing sign off...
by Mark Tompsett 27 Feb '18

27 Feb '18

Greetings, I was hoping that https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16690 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18908 and https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19547 might get signed off. GPML, Mark Tompsett

1 0

Koha Elastic Search, thanks to Orex
by Paul Poulain 26 Feb '18

26 Feb '18

Hello koha-devel, A big thanks to Hugo Agud and the Orex Spanish company for their sponsoring of BibLibre work on Elastic Search. We used this sponsoring to investigate ES 6.0 support. Alex already wrote a patch that has to be signed-off : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18969 PS: Hugo, (as many others) will be at the hackfest and we will have fun with Koha & ES !!! -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

1 0

Koha 17.05.09 release
by Fridolin SOMERS 23 Feb '18

23 Feb '18

The Koha community is proud to announce the release of Koha 17.05.09. This is a maintenance release. The full release notes are available at https://koha-community.org/koha-17-05-09-release/ Regards, -- Fridolin SOMERS <fridolin.somers(a)biblibre.com> BibLibre - software and system maintainer

1 0

Elasticsearch and facets
by Claes Eriksson 21 Feb '18

21 Feb '18

First some ranting about Zebra and then a question about ElasticSearch. Using Zebra there is a Global system pref. called maxRecordsForFacets. By default the number of records used to build the facet list is the first 20 results shown. You also get a warning in the manual to increase the number since it will impact respons time. Building a facet list out of 20 records may be enough for some people but if you think twice about it you realise that it is quite misleading, especially since the user does not know that the facet list is built on a very limited selection of records. Having the sort set on Author and searching for realivity theory, the facet list may not show Einstein if your library is specialised in physics and have a fairly large collection. I have high hopes for ElasticSearch to work with facets in a better way. The best would be if all the index could be used for producing e.g. the author facet and that it would have minimal impact on system performance. I understand that there is discussion about making facets configurable (bug 18235) but I cannot see any traces of the improvements I would like to see, but I may be wrong since I am quite new working with Koha. Regards Claes Eriksson, VTI, Sweden

4 6

Two authority reports that need your help
by Marcel de Rooy 19 Feb '18

19 Feb '18

Hi all, I need some help on two authority reports. [1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20074 Auth_subfield_structure changes hidden attribute Marked Major. Easy patch that deals with the logic to display or hide authority subfields. The current situation may turn hidden fields into displayed fields when editing the framework. It needs your signoff to get further. [2] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14769 Authorities merge: Set correct indicators in biblio field An enhancement in a longer line of reports that got pushed in the course of 2017 to improve authority merging. One of the last steps. It allows you to configure the indicators of a biblio field that is controlled by an authority. Including code from Janusz to handle special MARC21 exceptions. Julian already tested the UNIMARC side. It now needs a MARC21 signoff to get into the next stage. Please have a look. Thanks, Marcel

1 0