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

Re: [Koha-devel] [NEW_TOPIC] Getting bugs further
by Marcel de Rooy 13 Jan '17

13 Jan '17

> I guess there's no straight answer. It will depend on signoffers and QA people's opinion. People tend to focus on the stuff they care, lately, so that's why I said... > Sometimes people just drop some patches and wait for others to care about them. And it doesn't work like that most of the time. Shouldn’t we as a community do something about this evolving trend then? If we scare away developers by ignoring their patches, the community is not better off in the long run (imo). So, we should signoff or QA not only what we need or like. Isn’t that something for the bug wranglers too? Marcel

3 3

Re: [Koha-devel] Advice for testing bug 17710
by David Cook 12 Jan '17

12 Jan '17

I suppose in this case I rather be told what’s enough than doing my best and being told it’s not enough. I suppose we’re all time poor, but I don’t have 100% time on Koha anymore. Test::MockModule might work. Long term, it probably makes more sense to refactor get_matches, but I think it could work for now to show that the code I’m using works. Although in that case, should I put my sorting code as a function or copy and paste from the module into the test? I suppose any time a person says copy and paste, the answer is make a function… What do you mean by keep in touch with QA members? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Tomas Cohen Arazi [mailto:tomascohen@gmail.com] Sent: Thursday, 12 January 2017 11:56 AM To: David Cook <dcook(a)prosentient.com.au> Subject: Re: [Koha-devel] Advice for testing bug 17710 David, do your best and try to keep in touch with QA members. While we enforce the introduction of regression tests, there are exceptions. We usually get grumpy when tests are trivial, and we deduce laziness on the developer side. El mié., 11 de ene. de 2017 9:33 PM, David Cook <dcook(a)prosentient.com.au <mailto:dcook@prosentient.com.au> > escribió: Hi all, I wrote a little patch to make C4::Matcher::get_matches and C4::ImportBatch::GetBestRecordMatch use the same logic for sorting matches, so that matches are returned consistently in the same order. However, C4::Matcher::get_matches is basically spaghetti and relies on Zebra (and a hard-coded Zebra server at that), so I’m not sure how best to test it. I was thinking maybe turning the sorting into a little function and unit testing that. Would that be sufficient? In terms of manual testing, I think matching is mostly done behind the scenes, so it would be tough to verify the output of the sort… 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 <mailto:Koha-devel@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

2 1

FYI: yaz-client limitations
by Tomas Cohen Arazi 12 Jan '17

12 Jan '17

Barton told me it could be useful to share this excange I had with IdexData people during the implementation of the Zebra facets. It highlights a limitation on the yaz-client tool, and they suggest we better use zoomsh. I'm not sure if I already posted this on koha-devel, but it doesn't hurt to re-post, and might save some people some hours and headaches. Regards ---------- Forwarded message --------- From: Adam Dickmeiss <adam(a)indexdata.dk> Date: lun., 9 mar. 2015 a las 6:36 Subject: Re: [Info] Possible limit on the amount of specs on an elementset? [ZEB-663] To: Tomas Cohen Arazi <tomascohen(a)gmail.com> Cc: jira(a)indexdata.com <jira(a)indexdata.com> On 03/02/2015 12:18 PM, Tomas Cohen Arazi wrote: Hi, I compiled 2.0.60 with the aim to patch it for a problem we are facing, and I can say the problem I previously reported is still present: This a limitation in yaz-client which has a limit of 100 characters for elem command. We'll remove that limitiation. You can use zoomsh instead to play with longer facet specs. / Adam Z> elem zebra::facet::su-to:0:100,su-geo:0:100,su-ut:0:100,au:0:100,se:0:100,itype:0:100,location:0:100,holdingbranch:0:100,homebranch:0:100,tomas:0:100 Z> s 1+1 Sent presentRequest (1+1). Records: 1 Record type: XML <record xmlns="http://www.indexdata.com/zebra/"> <facet type="0" index="su-to"> </facet> <facet type="0" index="su-geo"> </facet> <facet type="0" index="su-ut"> </facet> <facet type="0" index="au"> <term coccur="2" occur="2">Adåker, Ulf</term> <term coccur="2" occur="2">Danielsson, Palle</term> <term coccur="2" occur="2">Stenson, Bobo</term> <term coccur="1" occur="1">Davis, Miles</term> <term coccur="1" occur="1">Löfcrantz, Johan</term> <term coccur="1" occur="1">Milder, Joakim</term> <term coccur="1" occur="1">Öström, Magnus</term> </facet> <facet type="0" index="se"> </facet> <facet type="0" index="itype"> </facet> <facet type="0" index="location"> </facet> <facet type="0" index="holdingbranch"> </facet> </record> nextResultSetPosition = 2 Elapsed: 0.001203 So 'holdingbranch' is the last facet it retrieves. If I thange the elementset like this: Z> elem zebra::facet::su-to:0:100,su-geo:0:100,su-ut:0:100,au:0:100,se:0:100,itype:0:100,location:0:100,tomas:0:100,homebranch:0:100,holdingbranch:0:100 I still get a 8 facet limit: Z> s 1+1 Sent presentRequest (1+1). Records: 1 Record type: XML <record xmlns="http://www.indexdata.com/zebra/"> <facet type="0" index="su-to"> </facet> <facet type="0" index="su-geo"> </facet> <facet type="0" index="su-ut"> </facet> <facet type="0" index="au"> <term coccur="2" occur="2">Adåker, Ulf</term> <term coccur="2" occur="2">Danielsson, Palle</term> <term coccur="2" occur="2">Stenson, Bobo</term> <term coccur="1" occur="1">Davis, Miles</term> <term coccur="1" occur="1">Löfcrantz, Johan</term> <term coccur="1" occur="1">Milder, Joakim</term> <term coccur="1" occur="1">Öström, Magnus</term> </facet> <facet type="0" index="se"> </facet> <facet type="0" index="itype"> </facet> <facet type="0" index="location"> </facet> <facet type="0" index="homebranch"> </facet> </record> nextResultSetPosition = 2 Elapsed: 0.003697 On Mon, Feb 9, 2015 at 5:08 PM, Tomas Cohen Arazi <tomascohen(a)gmail.com> wrote: Is there a way (or could it be) to skip the error if there are elems with results? For facets, it would be great that we could ask for n facets, and retrieve all at once. I'll try 2.0.59 in about two hours and reply. El lun., 9 de febrero de 2015 12:59, Adam Dickmeiss <adam(a)indexdata.dk> escribió: On 02/09/2015 04:51 PM, Tomas Cohen Arazi wrote: It is 2.0.44 on ubuntu 14.04. Should i try a newer? I don't see things changes with respect to facets.. But you could try 2.0.59 out. / Adam El lun., 9 de febrero de 2015 12:48, Adam Dickmeiss <adam(a)indexdata.dk> escribió: On 02/05/2015 11:27 AM, Adam Dickmeiss wrote: Hi Tomas, we'll look into this and get back to you. Please reply-all and keep [ZEB-663] contents in the subject line for future conversation. Hi Tomas, we can't see a limit of 8. Asking for more than 8 returns more than 8. And supplying any non-existing facet-field throws an error. What version of Zebra are you using? / Adam / Adam On 02/04/2015 03:59 PM, Tomas Cohen Arazi wrote: Hi, I've been playing with facets retrieval, which shines in Koha 3.18 (thanks!) One thing I noticed is that asking zebra to retrive more than 8 facets at once doesn't work (it only retrieves 8). What i did was: > elem zebra::facet::a1:0:20,...,a8:0:20,bullshit:0:20 ('bullshit' doesn't exist on the facet indexes) and > f a > s 1+1 shows the expected results. If I do > elem zebra::facet::a1:0:20,...,a7:0:20,bullshit:0:20 It fails ([25] Specified element set name not valid...) Regards -- Tomás Cohen Arazi Prosecretaría de Informática Universidad Nacional de Córdoba ✆ +54 351 5353750 ext 13168 <%2B54%20351%205353750%20ext%2013168> GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F _______________________________________________ Info mailing listInfo@lists.indexdata.dkhttp://lists.indexdata.dk/cgi-bin/mailman/listinfo/info -- Tomás Cohen Arazi Prosecretaría de Informática Universidad Nacional de Córdoba ✆ +54 351 5353750 ext 13168 <0351%20535-3750> GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

2 1

Advice for testing bug 17710
by David Cook 12 Jan '17

12 Jan '17

Hi all, I wrote a little patch to make C4::Matcher::get_matches and C4::ImportBatch::GetBestRecordMatch use the same logic for sorting matches, so that matches are returned consistently in the same order. However, C4::Matcher::get_matches is basically spaghetti and relies on Zebra (and a hard-coded Zebra server at that), so I'm not sure how best to test it. I was thinking maybe turning the sorting into a little function and unit testing that. Would that be sufficient? In terms of manual testing, I think matching is mostly done behind the scenes, so it would be tough to verify the output of the sort. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

2 1

KohaDevBox v2.0 released
by Tomas Cohen Arazi 11 Jan '17

11 Jan '17

After lots of months of work and people's contributions, we finally reached our milestone for v2.0. The original KohaDevBox functionalities are all implemented on the Ansible-driven one, and we can now focus on making it even better (we already have Elasticsearch integration, automatic superlibrarian user creation, and lots of configuration options). It can be used on Linux, Mac OS and Windows. It provides a full development and testing environment for people willing to work on the project. Read the README.md[1] file to get an idea of how easy is to get a full development environment, and the flexibility you can get with all the options we provide. Please enjoy it, and fill issues for any problem you might have. It can be improved, and we count on you to help us :-D Koha Development Team [1] https://github.com/digibib/kohadevbox -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

2 3

Zebra: the 'elements zebra::snippet' doesn't work
by Tajoli Zeno 11 Jan '17

11 Jan '17

Hi all, I trying to check my indexes in Zebra. My setup: OS: Debian jessie Koha: 3.20.7 [manual install] Zebra: 2.0.61 [install from IndexData repo] Format: UNIMARC Probably the fact that I use unimarc is relevant but I don't understand where. I do the debug described here: http://wiki.koha-community.org/wiki/Troubleshooting_Zebra#Why_does_a_search… The result of a working search is: Diagnostic message(s) from database: [25] Specified element set name not valid for specified database -- v2 addinfo 'zebra::snippet' but my ../etc/zebradb/retrieval-info-bib-dom.xml is correct: <?xml version="1.0" encoding="UTF-8"?> <retrievalinfo xmlns="http://indexdata.com/yaz"> <retrieval syntax="unimarc" name="F"> <backend syntax="xml" name="marc"> <marc inputformat="xml" outputformat="marc" inputcharset="utf-8" outputcharset="utf-8"/> </backend> </retrieval> <retrieval syntax="unimarc" name="B"> <backend syntax="xml" name="marc"> <marc inputformat="xml" outputformat="marc" inputcharset="utf-8" outputcharset="utf-8"/> </backend> </retrieval> <retrieval syntax="xml" /> <retrieval syntax="xml" name="index"/> <retrieval syntax="xml" name="marc" identifier="info:srw/schema/1/marcxml-v1.1"/> <retrieval syntax="xml" name="marcxml" identifier="info:srw/schema/1/marcxml-v1.1"/> <retrieval syntax="xml" name="zebra::*"/> </retrievalinfo> Do I need to check in other places for the setup of ' zebra::snippet' ? Bye Zeno Tajoli -- Zeno Tajoli / SVILUPPO PRODOTTI/ - Automazione Biblioteche Email: z.tajoli(a)cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)

5 13

Koha Development meeting reminder - 11 January 2016
by Nick Clemens 11 Jan '17

11 Jan '17

Hi All, The next Koha development meeting is on IRC tomorrow 11 January 2017 at 20:00 UTC You can see what that is in your local time here: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+I… <https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+I…> Agenda is here: https://wiki.koha-community.org/wiki/Development_IRC_meeting_11_January_2017 Please make sure to add any topics you wish to discuss. See you all soon!

2 1

Koha 16.11.01 released
by Katrin 10 Jan '17

10 Jan '17

The Koha community is proud to announce the release of Koha 16.11.01 This is the first maintenance release of 16.11 and contains several bugfixes. The full release notes are available at https://koha-community.org/koha-16-11-01-released Packages will be available soon. Happy holidays!

1 1

What's on in koha-devel #9
by Jonathan Druart 09 Jan '17

09 Jan '17

Hello librarians and developers, I wish you a happy new year, 2017 will be awesome, I am sure :) At least it will be a great year for your favourite ILS - Koha is constantly improving and next releases will be even better than the last ones, as always :) = Hea = Some of us are still a bit hesitant about Hea because of the lack of communication around this project. It also seems that we would like to improve this tool and the way it displays data, to make it more attractive. To answer the first need, Chris wrote a privacy policy file [2]. You can send us feedback about it if things are not clear enough. To improve data collected by Hea, I have opened 3 bug reports (actually 1 was already opened): Bug 14608 will add an administration page for Hea, to make it more visible and understandable Bug 17802 will collect ideas (and patches?) about adding geolocation of Koha's installations Bug 17803 introduce the idea of collecting the number of libraries per installation. It will permit to know how many libraries are actually using Koha (vs the number of installations). If you are interested in these topics, get involved on the mailing list or the corresponding bug reports. = Benchmarks for 16.11 = I have compared Koha versions from 3.14.x to 16.11. The results have been posted on the wiki [3]. Everybody can replay these benchmarks easily, and some of you must do it to confirm (or not) these numbers. One important thing is that I noticed that the template caching system is not defined by default - however it brings a significant performance boost. I have opened a bug report (Bug 7533 - Add template_cache_dir to the koha-conf.xml file) to add the entry to the koha-conf file. This patch will also add a warning to the about page if the entry is not defined. If you are running a Koha install hosted by a (good) service provider, it should be correctly defined. But if you are self-hosted, you must definitely take a look at this configuration option. To play these benchmarks I needed to rebuild a database for each of these different versions of Koha. This job leads me to modify the scripts from the koha-misc4dev [4] repository. With these scripts I am now able to get a Koha installation fully testable (items, reindexation, psgi file, etc.) with any of these versions in a few minutes. That should be very useful for developers, especially to benchmark, bisect, archaeological digs or simply debug. = Important bugs waiting for love = Last month I have sent an email to koha-devel to list several important bugs waiting to be tested or QAed. It was very helpful as (almost) all of them got the expected love and have been boosted quickly. Note that we always have these kinds of important bugs, and I will try to think about a way to keep a list of them. A simple and naive approach would be to list the major, critical and blocker ones on the dashboard. Any thoughts? The one we want to see in quickly for now is Bug 17817 - Repeat this Tag (cloning) not working It is waiting for QA. Furthermore if you are confident with SIP you should take a look at the different SIP patches in the needs signoff (17758 Major, 17665, 17826, 16755, 15418, 13666) and signed off queues (16757, 16895 and 16899). = Refactoring = == Remove the biblioitems.marcxml field == This is the last call! Bug 17196 has now 4 independent signoffs, we need (at least) 1 QA guy to have a look at it. If it is not pushed quickly, I will block its integration into the next release. We do not want it to be pushed close to the release date. == Koha::Patrons == I have started to replace the C4::Member::GetMember subroutine with Koha::Patrons. You can take a look at bug 17829 to see the progress (check the remote branch on github). It's a massive change as it impacts a lot of file and it depends on lot of other patches not pushed yet to master. Using Koha::Patron will allow us to improve the REST API routes for the patron module. Moreover it will permit to manipulate patron objects and so to call the new methods recently added to our Koha::Patron module. That will make the code more readable than at the moment: only 1 patron structure will be manipulated and not 1 Koha::Patron object + the hashref returned by GetMember. Doing so the patron object will be sent to the templates and that will clean up a lot of scripts from the "members" module. = Standardize our EXPORT = Last month I talked about bug 17600. It did not get lot of attention. If nobody gets involved in the discussion I will put it aside. = Template Toolkit syntax for notices = Since Kyle's topic on the koha mailing list [1] did not receive any objections I will try and coordinate with him to move forward on this subject. The next general IRC meeting is on February 1st, 14 UTC. https://wiki.koha-community.org/wiki/General_IRC_meeting_1_February_2017 The next dev IRC meeting is on January 11th, 20 UTC. https://wiki.koha-community.org/wiki/Development_IRC_meeting_11_January_2017 In 2 days! Hope to see your there! Cheers, Jonathan [1] Template Toolkit syntax for notices - https://lists.katipo.co.nz/pipermail/koha/2016-December/046773.html [2] Hea Privacy policy - http://git.koha-community.org/gitweb/?p=hea.git;a=blob;f=Privacy_Policy.md;… [3] Benchmark for 16.11 - https://wiki.koha-community.org/wiki/Benchmark_for_16.11 [4] koha-misc4dev - http://lists.koha-community.org/pipermail/koha-devel/2016-November/043277.h…

2 1

DBIC > Swagger object definition
by Tomas Cohen Arazi 09 Jan '17

09 Jan '17

In the process of writing a script for generating swagger object definitions our of DBIC schemas (for sort-of scaffolding them making easier to add REST endpoints) I resumed some talks we had at Marseille, and also picked some previous work from Lari on automating the Koha::Object <-> Swagger translation. One thing that would be handy for this process, is to add the column descriptions to the schema files. This can be accomplished like this example (for Koha::Schema::Result::BorrowerAttributeType): +__PACKAGE__->add_columns( + "+code" => { + koha_description => "Unique key used to identify the attribute type" + }, + "+description" => + { koha_description => "Description for the attribute type" }, + "+repeatable" => { + koha_description => + "Defines if a patron can have multiple values for the attribute type" + }, + "+unique_id" => { + koha_description => "Defines if the assinged value need to be unique" + }, + "+opac_display" => { + koha_description => + "Defines if the attribute is visible to patrons on their account in the OPAC or not" + }, + "+opac_editable" => { + koha_description => + "Defines if the attribute is editable by patrons on their account in the OPAC or not" + }, + "+staff_searchable" => { + koha_description => + "Defines if the attribute is searchable via the patron search in the staff client" + }, + "+authorised_value_category" => { + koha_description => + "Foreign key from authorised_values that links this attribute to an authorized value category" + }, + "+display_checkout" => { + koha_description => + "Defines if the attribute is displayed in checkout screens" + }, + "+category_code" => { + koha_description => + "Defines a constraint on a patron category for the attribute type" + }, + "+class" => + { koha_description => "Defines a class for grouping attributes" } +); This way we can have really simple access to those descriptions we already have in kohastructure.sql: my $columns_info = Koha::Database->new->schema->resultset('BorrowerAttributeType') ->result_source->columns_info; foreach $key ( keys %{ $columns_info } ) { print "Column: $key | Description: " . $columns_info->{$key}->{koha_description}; } This could be an easy initial task for academy bugs. Opinions? We will need this at some point if we would change our workflow and have DB structure handled by DBIC. Anyway, I'll send a pull request to Jonathan so he adds this handy (and perfectible) script to his koha-misc4dev repository. This will make it available on kohadevbox right out-of-the-box. I'll then try to document it on Kyle's Koha Developer Handbook, which we all should add our bits of knowledge! Looking forward to your feedback! -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

3 3