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

Koha Community Newsletter: September 2016
by kohanews 30 Sep '16

30 Sep '16

Fellow Koha users: The Koha Community Newsletter for September 2016 is here: https://koha-community.org/koha-community-newsletter-september-2016/ 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. Thanks! -- Chad Roseburg Editor, Koha Community Newsletter

1 0

Bug 5670: Housebound Module
by Alex Sassmannshausen 29 Sep '16

29 Sep '16

Hello, Whilst putting finishing touches on Bug 5670 Housebound Readers Module, a discussion was started on the best way to handle database architecture for a part of the feature. Jonathan, who has been heavily involved in reviewing the patch series so far, quite rightly suggested we get some additional opinions. You can read the discussion on the bug (it's quite old, the last few comments are probably most relevant), but as a summary (primarily of my perspective): The housebound module relies on assigning one or two roles to patrons registered in Koha. Patrons can be 'deliverers' (delivering items to housebound patrons), 'choosers' (selecting items which can then be delivered by deliverers), or both. The current implementation uses extended patron attributes, but I would agree that this implementation is probably sub-optimal for the use case of the Housebound module. We are now debating whether it is better to add 2 new columns to the borrowers table (increasing the number of columns from 69 to 71), for the two new roles, or whether we should create a new table, called 'housebound_role' to go with 'housebound_profile' and 'housebound_visit', which consists of - borrower_id (foreign key to borrowers.borrowernumber) - deliverer (boolean) - chooser (boolean) My personal feeling is that the latter approach is better for the following reasons: - Housebound module is an optional feature switched on in sysprefs. - For the sites that enable it, I would expect that only a small percentage of all registered patrons become volunteers As a result, the housebound_role table will be empty for sites that have the feature disabled, and small for sites that have it enabled. Going with the former approach will implicitly create values for every patron in the installation, even if the feature is switched off. For future development, making changes to the housebound_role table would be less intrusive than making changes to the borrowers table. Finally, from a data integrity perspective, I cannot see either approach being better or worse at this point: the foreign key constraint will ensure data integrity, and the table is normalized in either case (though I'm certainly not an expert in this area). WDYT? Best wishes, Alex

2 1

Re: [Koha-devel] Elasticsearch not searching.
by Tomas Cohen Arazi 29 Sep '16

29 Sep '16

Its ok if you want to try ElasticSearch even though it is experimental. But aren't you migrating a production service? El jue., 29 sept. 2016 a las 9:57, Rodrigo Santellan (<rsantellan(a)gmail.com>) escribió: > Tomas, > > I have attached all the vagrant files. > > For installing it I use: > - vagrant up > - vagrant ssh > - sudo sh /vagrant/provisioning/enviromentsSettings.sh > - exit > - vagrant ssh > - sh /vagrant/provisioning/fullProvisioning.sh > - sh /vagrant/provisioning/makeKoha.sh #Choose the dev installation > - sudo sh /vagrant/provisioning/apacheEnviroment.sh > - sudo systemctl restart apache2 > - sudo systemctl restart mysql > - cd /vagrant/provisioning/kohaMigrationData/ > - gunzip < koha.sql.gz | mysql -u root -p # Old instance of koha 2.2.3 > - cat /vagrant/provisioning/koha3-schema.sql | mysql -u root -p > - nohup ./importData.sh > - mv nohup nohup.importdata > - nohup ./runscripts.sh > > I'm running all the scripts that I need by hand. > > I'm trying to understand the new (for me) Koha so I can maximize the time > I have to work on it, thats why I don't run the packages installer. I also > have the problem that I know I have to modify it :( > > Thanks for the help! > > > On Thu, Sep 29, 2016 at 9:38 AM, Tomas Cohen Arazi <tomascohen(a)gmail.com> > wrote: > >> Dood, just: >> - launch a clean VBox with Debian 8 or Ubuntu 16.04 >> - install mysql-server (in Ubuntu 16.04 install mariadb-server) >> - Add the repo, install koha-common >> - $ sudo koha-create --create-db test_library >> >> And that's all of it. It is working for everyone else, so please try to >> write some more detailed install/setup steps so we understand what's going >> on. >> >> PS: if this was a dev box, you need https://github.com/mkfifo/koha-gitify >> >> El jue., 29 sept. 2016 a las 9:31, Rodrigo Santellan (< >> rsantellan(a)gmail.com>) escribió: >> >>> David, >>> >>> I tried running the Kohadevbox but I have fail because I'm behind a >>> proxy and the provisioning fails and I can't start up the machine. >>> >>> So my next step was to create a empty Vagrant with the box: >>> bento/ubuntu-16.04 and run post install scripts. >>> >>> The default version installed on ubuntu 16.04 is: >>> >>> idzebra-2.0: >>> Installed: 2.0.59-1 >>> Candidate: 2.0.59-1 >>> >>> I have successfully run the searches with Elasticsearch. Now I have to >>> see if I'm missing something or not because using Elasticsearch instead of >>> Zebra! >>> >>> Thanks for your help! >>> >>> Regards >>> >>> >>> On Wed, Sep 28, 2016 at 10:04 PM, David Cook <dcook(a)prosentient.com.au> >>> wrote: >>> >>>> Also, if you're having issues with Zebra, you can try posting to this >>>> list, >>>> as there are a number of us who can probably help you. >>>> >>>> I see that you posted before about trying to see how many biblios are >>>> indexed in Zebra, and that you had a problem using _ALLRECORDS. Did you >>>> have >>>> any other problems? Were you able to successfully perform other Zebra >>>> searches? >>>> >>>> I admit that the error "[114] Unsupported Use attribute -- v2 addinfo >>>> '_ALLRECORDS'" is rather difficult to figure out. Usually, if you see >>>> that >>>> 114 code, it means that a particular index hasn't been created yet >>>> within >>>> the Zebra database*. However, since you're using the special index >>>> _ALLRECORDS, it should be created. >>>> >>>> It looks like you're using Zebra 2.0.44. That should support >>>> _ALLRECORDS. >>>> I'm on Zebra 2.0.60, and this is the output I see: >>>> >>>> Z> find @attr 1=_ALLRECORDS @attr 2=103 "" >>>> Sent searchRequest. >>>> Received SearchResponse. >>>> Search was a success. >>>> Number of hits: 956, setno 2 >>>> SearchResult-1: term= cnt=956 >>>> records returned: 0 >>>> Elapsed: 0.010064 >>>> >>>> I just tried It on a Debian server running Zebra 2.0.44 and I see this >>>> output: >>>> Z> find @attr 1=_ALLRECORDS @attr 2=103 "" >>>> Sent searchRequest. >>>> Received SearchResponse. >>>> Search was a success. >>>> Number of hits: 14882, setno 1 >>>> SearchResult-1: term= cnt=14882 >>>> records returned: 0 >>>> Elapsed: 0.028209 >>>> >>>> Even if I delete all the records in my database, I still see: >>>> >>>> Z> find @attr 1=_ALLRECORDS @attr 2=103 "" >>>> Sent searchRequest. >>>> Received SearchResponse. >>>> Search was a success. >>>> Number of hits: 0, setno 1 >>>> SearchResult-1: term= cnt=0 >>>> records returned: 0 >>>> Elapsed: 0.007409 >>>> >>>> Your Zebra database "biblios" appears to be created otherwise you'd see: >>>> >>>> Z> find @attr 1=_ALLRECORDS @attr 2=103 "" >>>> Sent searchRequest. >>>> Received SearchResponse. >>>> Search was a bloomin' failure. >>>> Number of hits: 0, setno 1 >>>> Result Set Status: none >>>> records returned: 0 >>>> Diagnostic message(s) from database: >>>> [109] Database unavailable -- v2 addinfo 'biblios' >>>> Elapsed: 0.001682 >>>> >>>> Hmm... my best guess is that somehow your Zebra install has been >>>> corrupted >>>> maybe. I'm not really sure. This is a very bizarre error. >>>> >>>> How did you install Koha and Zebra? I notice the home directory for a >>>> vagrant user... is this a Kohadevbox? >>>> >>>> >>>> >>>> >>>> >>>> >>>> * >>>> In this particular database, I've only ever had 1 record, and it >>>> contained >>>> very little data. It contained a title, so the following search works: >>>> Z> find @attr 1=4 "test" >>>> Sent searchRequest. >>>> Received SearchResponse. >>>> Search was a success. >>>> Number of hits: 0, setno 5 >>>> SearchResult-1: term=test cnt=0 >>>> records returned: 0 >>>> Elapsed: 0.002783 >>>> >>>> However, the record never contained an author, so the following search >>>> fails >>>> with that Error 114: >>>> Z> find @attr 1=1 "Bob" >>>> Sent searchRequest. >>>> Received SearchResponse. >>>> Search was a bloomin' failure. >>>> Number of hits: 0, setno 6 >>>> Result Set Status: none >>>> records returned: 0 >>>> Diagnostic message(s) from database: >>>> [114] Unsupported Use attribute -- v2 addinfo '1' >>>> Elapsed: 0.000289 >>>> >>>> David Cook >>>> Systems Librarian >>>> Prosentient Systems >>>> 72/330 Wattle St >>>> Ultimo, NSW 2007 >>>> Australia >>>> >>>> Office: 02 9212 0899 >>>> Direct: 02 8005 0595 >>>> >>>> >>>> > -----Original Message----- >>>> > From: koha-devel-bounces(a)lists.koha-community.org [mailto:koha-devel- >>>> > bounces(a)lists.koha-community.org] On Behalf Of Chris Cormack >>>> > Sent: Thursday, 29 September 2016 6:53 AM >>>> > To: Rodrigo Santellan <rsantellan(a)gmail.com> >>>> > Cc: koha-devel <koha-devel(a)lists.koha-community.org> >>>> > Subject: Re: [Koha-devel] Elasticsearch not searching. >>>> > >>>> > * Rodrigo Santellan (rsantellan(a)gmail.com) wrote: >>>> > > Chris I will install Elastic 1.7 and try again!! It should be on the >>>> > > wiki or the bugzilla issue that tracks the elasticsearch >>>> development. >>>> > > >>>> > > Thank a lot for the quick response! >>>> > >>>> > You could also follow this bug >>>> > >>>> > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17255 >>>> > >>>> > It may be that with the new packages there, it might work already. >>>> > It hasnt been tested yet though >>>> > >>>> > Chris >>>> > >>>> > > >>>> > > On Wed, Sep 28, 2016 at 5:43 PM, Chris Cormack < >>>> chrisc(a)catalyst.net.nz> >>>> > wrote: >>>> > > >>>> > > Hi Rodrigo >>>> > > >>>> > > ElasticSearch in Koha currently only works with Elastic 1.7 >>>> > > We are working on upgrading it to working the latest version but >>>> there >>>> > > were some non backward compatible changes. That is what you are >>>> > bumping >>>> > > into >>>> > > >>>> > > Support in Koha is still experimental, but it once we upgrade it >>>> should be >>>> > > more >>>> > > solid. >>>> > > >>>> > > You could try installing 1.7 and seeing how you go >>>> > > >>>> > > Chris >>>> > > >>>> > > >>>> > > * Rodrigo Santellan (rsantellan(a)gmail.com) wrote: >>>> > > > Hi, >>>> > > > >>>> > > > I have installed Elasticsearch after giving up on Zebra. I >>>> have >>>> follow >>>> > > the the >>>> > > > wiki: https://wiki.koha-community.org/wiki/Elasticsearch# >>>> > > Install_elasticsearch >>>> > > > and installed latest Elasticsearch through the official >>>> repository. >>>> > > > >>>> > > > My installed version is: >>>> > > > curl -XGET 'localhost:9200' >>>> > > > { >>>> > > > "name" : "Her", >>>> > > > "cluster_name" : "elasticsearch", >>>> > > > "cluster_uuid" : "yuU4XtZwT1WtK1SH-3Xofw", >>>> > > > "version" : { >>>> > > > "number" : "2.4.1", >>>> > > > "build_hash" : "c67dc32e24162035d18d6fe1e952c4cbcbe79d16", >>>> > > > "build_timestamp" : "2016-09-27T18:57:55Z", >>>> > > > "build_snapshot" : false, >>>> > > > "lucene_version" : "5.5.2" >>>> > > > }, >>>> > > > "tagline" : "You Know, for Search" >>>> > > > } >>>> > > > >>>> > > > I have run the script perl >>>> misc/search_tools/rebuild_elastic_search.pl -v >>>> > > -d >>>> > > > like the documentation says and I have this error: >>>> > > > Failed to parse mapping [data]: analyzer on field >>>> [Local-number] >>>> must >>>> > be >>>> > > set >>>> > > > when search_analyzer is set >>>> > > > >>>> > > > The log on the elasticsearch.log is >>>> > > > >>>> > > > [2016-09-28 20:27:55,272][DEBUG][action.admin.indices.create] >>>> [Her] >>>> > > > [koha_dev_biblios] failed to create >>>> > > > MapperParsingException[Failed to parse mapping [data]: >>>> analyzer on >>>> > field >>>> > > > [Local-number] must be set when search_analyzer is set]; >>>> nested: >>>> > > > MapperParsingException[analyzer on field [Local-number] must >>>> be >>>> set >>>> > when >>>> > > > search_analyzer is set]; >>>> > > > at org.elasticsearch.index.mapper.MapperService.merge >>>> > > > (MapperService.java:291) >>>> > > > at >>>> > > > >>>> > >>>> org.elasticsearch.cluster.metadata.MetaDataCreateIndexService$1.execute >>>> > > > (MetaDataCreateIndexService.java:317) >>>> > > > at >>>> org.elasticsearch.cluster.ClusterStateUpdateTask.execute >>>> > > > (ClusterStateUpdateTask.java:45) >>>> > > > at >>>> > > > org.elasticsearch.cluster.service.InternalClusterService. >>>> > > runTasksForExecutor >>>> > > > (InternalClusterService.java:468) >>>> > > > at >>>> > > > >>>> > >>>> org.elasticsearch.cluster.service.InternalClusterService$UpdateTask.run >>>> > > > (InternalClusterService.java:772) >>>> > > > at >>>> > > > >>>> > >>>> org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$ >>>> > > TieBreakingPrioritizedRunnable.runAndClean >>>> > > > (PrioritizedEsThreadPoolExecutor.java:231) >>>> > > > at >>>> > > > >>>> > >>>> org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$ >>>> > > TieBreakingPrioritizedRunnable.run >>>> > > > (PrioritizedEsThreadPoolExecutor.java:194) >>>> > > > at java.util.concurrent.ThreadPoolExecutor.runWorker >>>> > > > (ThreadPoolExecutor.java:1142) >>>> > > > at java.util.concurrent.ThreadPoolExecutor$Worker.run >>>> > > > (ThreadPoolExecutor.java:617) >>>> > > > at java.lang.Thread.run(Thread.java:745) >>>> > > > Caused by: MapperParsingException[analyzer on field >>>> [Local-number] >>>> > must >>>> > > be set >>>> > > > when search_analyzer is set] >>>> > > > at >>>> > > > org.elasticsearch.index.mapper.core.TypeParsers. >>>> > > parseAnalyzersAndTermVectors >>>> > > > (TypeParsers.java:234) >>>> > > > at >>>> org.elasticsearch.index.mapper.core.TypeParsers.parseTextField >>>> > > > (TypeParsers.java:250) >>>> > > > at >>>> > > > >>>> > org.elasticsearch.index.mapper.core.StringFieldMapper$TypeParser.parse >>>> > > > (StringFieldMapper.java:165) >>>> > > > at >>>> > > > org.elasticsearch.index.mapper.object.ObjectMapper$ >>>> > > TypeParser.parseProperties >>>> > > > (ObjectMapper.java:309) >>>> > > > at >>>> > > > org.elasticsearch.index.mapper.object.ObjectMapper$TypeParser. >>>> > > parseObjectOrDocumentTypeProperties >>>> > > > (ObjectMapper.java:222) >>>> > > > at >>>> > > > >>>> > org.elasticsearch.index.mapper.object.RootObjectMapper$TypeParser.pars >>>> > e >>>> > > > (RootObjectMapper.java:139) >>>> > > > at >>>> org.elasticsearch.index.mapper.DocumentMapperParser.parse >>>> > > > (DocumentMapperParser.java:118) >>>> > > > at >>>> org.elasticsearch.index.mapper.DocumentMapperParser.parse >>>> > > > (DocumentMapperParser.java:99) >>>> > > > at org.elasticsearch.index.mapper.MapperService.parse >>>> > > > (MapperService.java:549) >>>> > > > at org.elasticsearch.index.mapper.MapperService.merge >>>> > > > (MapperService.java:319) >>>> > > > at org.elasticsearch.index.mapper.MapperService.merge >>>> > > > (MapperService.java:289) >>>> > > > ... 9 more >>>> > > > >>>> > > > I'm again at a loss, I believe the problem is on the method: >>>> > > > get_elasticsearch_mappings in Koha::ElasticSearch but I don't >>>> know >>>> > how to >>>> > > > follow it.! >>>> > > > >>>> > > > Regards and thank for any help!! >>>> > > > >>>> > > > Rodrigo >>>> > > >>>> > > > _______________________________________________ >>>> > > > Koha-devel mailing list >>>> > > > Koha-devel(a)lists.koha-community.org >>>> > > > >>>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>>> > > > website : http://www.koha-community.org/ >>>> > > > git : http://git.koha-community.org/ >>>> > > > bugs : http://bugs.koha-community.org/ >>>> > > >>>> > > >>>> > > -- >>>> > > Chris Cormack >>>> > > Catalyst IT Ltd. >>>> > > +64 4 803 2238 >>>> > > PO Box 11-053, Manners St, Wellington 6142, New Zealand >>>> > > >>>> > > >>>> > >>>> > > _______________________________________________ >>>> > > Koha-devel mailing list >>>> > > Koha-devel(a)lists.koha-community.org >>>> > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>>> > > website : http://www.koha-community.org/ git : >>>> > > http://git.koha-community.org/ bugs : >>>> http://bugs.koha-community.org/ >>>> > >>>> > >>>> > -- >>>> > Chris Cormack >>>> > Catalyst IT Ltd. >>>> > +64 4 803 2238 >>>> > PO Box 11-053, Manners St, Wellington 6142, New Zealand >>>> >>>> >>>> >>> _______________________________________________ >>> Koha-devel mailing list >>> Koha-devel(a)lists.koha-community.org >>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>> website : http://www.koha-community.org/ >>> git : http://git.koha-community.org/ >>> bugs : http://bugs.koha-community.org/ >> >> -- >> Tomás Cohen Arazi >> Theke Solutions (https://theke.io <http://theke.io/>) >> ✆ +54 9351 3513384 >> GPG: B2F3C15F >> > > -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

1 0

Elasticsearch not searching.
by Rodrigo Santellan 29 Sep '16

29 Sep '16

Hi, I have installed Elasticsearch after giving up on Zebra. I have follow the the wiki: https://wiki.koha-community.org/wiki/Elasticsearch#Install_elasticsearch and installed latest Elasticsearch through the official repository. My installed version is: curl -XGET 'localhost:9200' { "name" : "Her", "cluster_name" : "elasticsearch", "cluster_uuid" : "yuU4XtZwT1WtK1SH-3Xofw", "version" : { "number" : "2.4.1", "build_hash" : "c67dc32e24162035d18d6fe1e952c4cbcbe79d16", "build_timestamp" : "2016-09-27T18:57:55Z", "build_snapshot" : false, "lucene_version" : "5.5.2" }, "tagline" : "You Know, for Search" } I have run the script perl misc/search_tools/rebuild_elastic_search.pl -v -d like the documentation says and I have this error: Failed to parse mapping [data]: analyzer on field [Local-number] must be set when search_analyzer is set The log on the elasticsearch.log is [2016-09-28 20:27:55,272][DEBUG][action.admin.indices.create] [Her] [koha_dev_biblios] failed to create MapperParsingException[Failed to parse mapping [data]: analyzer on field [Local-number] must be set when search_analyzer is set]; nested: MapperParsingException[analyzer on field [Local-number] must be set when search_analyzer is set]; at org.elasticsearch.index.mapper.MapperService.merge(MapperService.java:291) at org.elasticsearch.cluster.metadata.MetaDataCreateIndexService$1.execute(MetaDataCreateIndexService.java:317) at org.elasticsearch.cluster.ClusterStateUpdateTask.execute(ClusterStateUpdateTask.java:45) at org.elasticsearch.cluster.service.InternalClusterService.runTasksForExecutor(InternalClusterService.java:468) at org.elasticsearch.cluster.service.InternalClusterService$UpdateTask.run(InternalClusterService.java:772) at org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$TieBreakingPrioritizedRunnable.runAndClean(PrioritizedEsThreadPoolExecutor.java:231) at org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$TieBreakingPrioritizedRunnable.run(PrioritizedEsThreadPoolExecutor.java:194) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: MapperParsingException[analyzer on field [Local-number] must be set when search_analyzer is set] at org.elasticsearch.index.mapper.core.TypeParsers.parseAnalyzersAndTermVectors(TypeParsers.java:234) at org.elasticsearch.index.mapper.core.TypeParsers.parseTextField(TypeParsers.java:250) at org.elasticsearch.index.mapper.core.StringFieldMapper$TypeParser.parse(StringFieldMapper.java:165) at org.elasticsearch.index.mapper.object.ObjectMapper$TypeParser.parseProperties(ObjectMapper.java:309) at org.elasticsearch.index.mapper.object.ObjectMapper$TypeParser.parseObjectOrDocumentTypeProperties(ObjectMapper.java:222) at org.elasticsearch.index.mapper.object.RootObjectMapper$TypeParser.parse(RootObjectMapper.java:139) at org.elasticsearch.index.mapper.DocumentMapperParser.parse(DocumentMapperParser.java:118) at org.elasticsearch.index.mapper.DocumentMapperParser.parse(DocumentMapperParser.java:99) at org.elasticsearch.index.mapper.MapperService.parse(MapperService.java:549) at org.elasticsearch.index.mapper.MapperService.merge(MapperService.java:319) at org.elasticsearch.index.mapper.MapperService.merge(MapperService.java:289) ... 9 more I'm again at a loss, I believe the problem is on the method: get_elasticsearch_mappings in Koha::ElasticSearch but I don't know how to follow it.! Regards and thank for any help!! Rodrigo

4 6

Hackfest in Marseille (last call, some news)
by Paul Poulain 28 Sep '16

28 Sep '16

Hi all, 63 persons have registred to the hackfest, in 2 weeks. People will come from 13 different countries: Argentina 1 Belgium 1 CZ 1 France 41 Germany 2 Italy 3 Norway 2 NZ 1 Sweden 1 Switzerland 1 UK 3 USA 6 Grand Total 63 And they'll represent 33 institutions: AARome 2 ACPL 1 Admin Kuhn 1 Arts-UK 1 BDP Meuse 2 BibLibre 17 Bleone-Verdon 2 BSZ 1 BULAC 2 ByWaterSolutions 5 CIRAD 2 ENS Cachan 1 IEP Grenoble 1 Koha 1 Libriotech 1 Living Libraries 1 Mines Paristech 1 Mirko Tietgen 1 Musée histoire immigration 1 Organisation 1 Oslo Public Library 1 PTFS-Europe 3 PUSC 1 R-Bit Technology, s.r.o. 1 Roubaix 1 SAN-OP 1 Sciences po Grenoble 2 SUB Stockholm 1 Theke 1 Univ Aix Marseille 3 Univ Lyon 3 1 Univ Paris 8 1 Université Lyon 2 1 Grand Total 63 It's still time to add your name, your country and/or your organization if you want ! -- 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

Re: [Koha-devel] Improving the API for record imports (Tomas Cohen Arazi)
by Benjamin Rokseth 28 Sep '16

28 Sep '16

Hi, Tomas and David, we have already implemented and are using a biblio CRUD endpoint, and I know the Finland community has, too. Sorry for not starting with a koha bug, but we simply didn't have the time... Now, we would very much like to add /change this to a Koha native bug, but for now, heres our local patch: https://github.com/digibib/koha-docker/blob/master/koha-patched/patches/130… which is based on koha master. Mainly, it reproduces the svc/biblio endpoint using marcxml for add/update, and some other expansions for GETting an expanded record with items. It was quite easy to implement using Koha Objects. Please don't hesitate to shoot us, I mean, ask us for more! Benjamin Rokseth Oslo Public Library ________________________________________ Fra: koha-devel-bounces(a)lists.koha-community.org <koha-devel-bounces(a)lists.koha-community.org> på vegne av koha-devel-request(a)lists.koha-community.org <koha-devel-request(a)lists.koha-community.org> Sendt: 27. september 2016 12:00 Til: koha-devel(a)lists.koha-community.org Emne: Koha-devel Digest, Vol 130, Issue 56 Send Koha-devel mailing list submissions to koha-devel(a)lists.koha-community.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel or, via email, send a message with subject or body 'help' to koha-devel-request(a)lists.koha-community.org You can reach the person managing the list at koha-devel-owner(a)lists.koha-community.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Koha-devel digest..." Today's Topics: 1. Re: Improving the API for record imports (Tomas Cohen Arazi) ---------------------------------------------------------------------- Message: 1 Date: Mon, 26 Sep 2016 12:56:20 +0000 From: Tomas Cohen Arazi <tomascohen(a)gmail.com> To: David Cook <dcook(a)prosentient.com.au>, Koha Devel <koha-devel(a)lists.koha-community.org> Subject: Re: [Koha-devel] Improving the API for record imports Message-ID: <CABZfb=WGH0gCH5veYjHmQEc4n1t+eoLsUmtUwMRceqW3tksLsA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" David, I agree with your ideas. Having a REST endpoint handling records would be awesome improvement. I'll hapilly sign or QA those patches. Regards El mi?., 21 sept. 2016 a las 22:00, David Cook (<dcook(a)prosentient.com.au>) escribi?: > Hi all, > > > > I want to improve the API(s) for importing (bibliographic) records. > > > > But I?m not 100% sure how to go about what criteria to use to gauge > ?improvement?. Here are some ideas: > > > > ? I think the REST API offers up one obvious addition and that?s > DELETE. It would be great to delete records using the API. I?ve found this > mostly thanks to OAI-PMH where you get a notice when a record has been > deleted upstream and needs to be deleted from Koha too. > > o The difficulty in deleting bibliographic records is items. If there > are items, it blocks the delete. You could auto-delete items, but you can?t > if there are holds or if it?s currently issued. At best, you could return a > failed delete via the API, I think. > > > > ? I keep thinking that ?import profiles? could be a good way to > go too. This might include a MARC Modification Template, it might be a > XSLT, it might be a Koha::Filter. It would let you turns your incoming > metadata from format A to format B. > > o This would also allow you to POST a minimum amount of data to the > API. You?d have your metadata record and your import profile code. > > ? The downside of this is the POST wouldn?t detail the options for the > import, and those imports would be more obfuscated. Changes to a profile > could also impact subsequent imports unintentionally. > > o I?m not sure how batches would work with filtering. You might have > 50/100 records filter correctly and import, but that leaves 50 which aren?t > imported. Do you undo the whole import, or do you fix your filter, and then > re-import the first 50 alongside the first time import of the last 50? > > > > ? The original metadata would be stored regardless of metadata > format (e.g. marcxml, mods, rdf, dc, etc.) for historical purposes or to > allow re-filtering in the event that a filter fails to correctly transform > a record to valid MARCXML (or whatever internal metadata format Koha uses). > > > > ? The import source and the type of import would be stored (ie > http://oai-server.com and ?oai-pmh?, lx2.loc.gov and ?z3950?, <insert > relevant source> and ?oclc connexion?, etc.). > > o I think this would be helpful for managing/processing a certain type > of import, perhaps also in terms of matching records. > > o At the moment, with my work on #10662, I have a separate table > ?import_oai? which obviously is for records imported via oai-pmh only. I > don?t actually track the origin due to how I currently source the imports, > but I could do it in the future. > > > > ? Storing some sort of identifier would be good > > o OAI-PMH records have unique identifiers for the records > > o Z39.50? that?s tougher since it?s not a specific metadata format like > the OAI-PMH format. So I don?t know about this one. > > > > Anyway, these are just some ideas I?ve been having. They?re not fully > formed by any stretch of the imagination. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Direct: 02 8005 0595 > > > _______________________________________________ > Koha-devel mailing list > Koha-devel(a)lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -- Tom?s Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ? +54 9351 3513384 GPG: B2F3C15F

3 2

Meeting Reminder: Development IRC meeting 28 September 2016
by Katrin Fischer 27 Sep '16

27 Sep '16

Hi all, there is a Development IRC Meeting scheduled for 28 September 2016, 21 UTC. The agenda and the time converter can as always be found on the wiki: https://wiki.koha-community.org/wiki/Development_IRC_meeting_28_September_2… Please add any topics you want to discuss! Hope to see you there, Katrin

1 0

RPMs for Koha (Fedora, RHEL, openSUSE, etc)
by David Cook 23 Sep '16

23 Sep '16

Hi all, I'm curious how many people are using RPM-based operating systems for running Koha. I know the majority are probably using Debian/Ubuntu, but I reckon there's probably more Fedora/RHEL/openSUSE folk than we might think! I noticed back in 2013 that Nicholas van Oudt had put together a RPM for Koha for Fedora. The link in nabble didn't work anymore, but I'm curious how many people have their own RPM spec files drifting around. I taught myself how to package RPMs back in June, and I package RPMs for a different much smaller Perl project, but I'm not willing to be a RPM manager for Koha. That said, I'm happy to test and QA RPM spec files. The cpanspec tool in Fedora/EPEL is also amazing for converting CPAN modules into RPMs. The openSUSE version is awful unfortunately, and I haven't had time yet to investigate with the openSUSE people about fixing it. I've noticed a few SELinux commands in some Koha code as well. I think Marcel might have included those. I think a reasonable alternative would be to do a custom policy module for Koha, which perhaps could be hosted in a community yum repository. We use openSUSE, so I wouldn't be looking to support Fedora/RHEL myself, but maybe if we started making some infrastructure, it could make it easier for the RPM using members of the Koha community. I know many are probably fearful of opening the door to RPMs since it could make support more difficult. so maybe we could have anything RPM-related be unofficial. Maybe treat it like contribs instead of part of Koha proper. Anyway, just an idea. If nothing else, maybe we RPM-based Koha people could put together a listserv to share RPM-based system issues. That could in theory relieve pressure from the Debian users when people ask them how to install Koha on CentOS/Fedora/RHEL, etc.? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

2 1

Zebra indexing
by Rodrigo Santellan 22 Sep '16

22 Sep '16

2 2

Curiosity why is cardnumber field size 16?
by Indranil Das Gupta 22 Sep '16

22 Sep '16

Hi all, I'm curious to know why is Koha's cardnumber field in borrowers table is historically set to VARCHAR(16) rather than say VARCHAR(255)? Especially since we now have the CardnumberLength syspref which we could use to drive the length rather than hardcode it down at 16. The background of this question: Schools in Nigeria use a matriculation number which is often larger than 16, as their cardnumber. Zeno did mention to me in a FB post that ExtendedPatronAttribute would equally do the job. Thoughts? -indranil -- Indranil Das Gupta L2C2 Technologies Phone : +91-98300-20971 Blog : http://blog.l2c2.co.in IRC : indradg on irc://irc.freenode.net Twitter : indradg

6 5