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

Looking for installdir... and bug 7167
by Mathieu Saby 24 Sep '13

24 Sep '13

Hi I would like to get the name of installation directory for putting in etc/..... a YAML file for configuring facets. I have been looking at the patch introducing SolR, and I found in "Koha / Koha / SearchEngine / Solr / Config.pm" this line : default => C4::Context->config("installdir") . qq{/etc/searchengine/solr/indexes.yaml}, That's exacty what I want... Except there is no "installdir" in my koha-conf.xml. In fact, I think it was introduced in this attachment http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6415 made for Bug 7167 As Bug 7167 has been reverted, installdir does not exist anymore. But it has "Passed QA" again after it was revert. So, could you tell me if this bug will be pushed into master? And if not, what can I do to get the value of the installation directory ? Regards, M. Saby -- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby(a)univ-rennes2.fr

3 5

deprecating zebra grs1 one day?
by Mathieu Saby 24 Sep '13

24 Sep '13

Hi As you know, making patches for Zebra has always be a nightmare. Now that DOM indexing is possible, it is a double nightmare, because you need to change 2 mores files (sometimes 4 more files when the bug is related to Marc21 and Unimarc). Unimarc conf files are not yet DOM compliant, but I have made some bugs which were signed off recently, and I hope they will soon pass QA. So, when it is done, so you think we could some day (for 3.14 ? 3.16?) get rid of Zebra GRS1 ? It could make simple further improvements. For example, I would like to make a page for configuring zebra indexes from staff interface. I think it can be done by parsing bib1, ccl.properties and xml DOM conf files. But I don't want to parse record.abs... Regards, M. Saby -- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby(a)univ-rennes2.fr

8 15

: deprecating zebra grs1 / query parser
by David Cook 24 Sep '13

24 Sep '13

+1 for deprecation of GRS1 +1 for query parser by default David Cook Systems Librarian (BA,FRLS,MLIS) Prosentient Systems P/L ABN 31 078 409 168 72/330 Wattle St, Ultimo NSW 2007 tel: 02 92120899 fax: 02 92120885 dcook(a)prosentient.com.au -----Original Message----- Message: 5 Date: Tue, 24 Sep 2013 14:50:39 +1200 From: Chris Cormack <chrisc(a)catalyst.net.nz> To: koha-devel(a)lists.koha-community.org Subject: Re: [Koha-devel] deprecating zebra grs1 one day? Message-ID: <3358a65f-8078-4b4b-8804-9b9e35669c61(a)email.android.com> Content-Type: text/plain; charset=UTF-8 Jared Camins-Esakov <jcamins(a)cpbibliography.com> wrote: >+1 for deprecation +1 from me too Chris > >On Mon, Sep 23, 2013 at 8:42 PM, Galen Charlton <gmc(a)esilibrary.com> >wrote: > >> Hi, >> >> On Sun, Sep 22, 2013 at 10:55 AM, Mathieu Saby < >> mathieu.saby(a)univ-rennes2.fr> wrote: >> >>> So, when it is done, so you think we could some day (for 3.14 ? >3.16?) >>> get rid of Zebra GRS1 ? It could make simple further improvements. >>> For example, I would like to make a page for configuring zebra >indexes >>> from staff interface. I think it can be done by parsing bib1, >>> ccl.properties and xml DOM conf files. But I don't want to parse >>> record.abs... >>> >> >> I don't think there's anything GRS-1 does that DOM cannot do. It's >too >> late by far to consider removing GRS-1 support for 3.14, but it is >not too >> late to make a deprecation announcement with the release of 3.14 and >plan >> on having it be removed in the release after 3.14 (or the release >after >> that). >> >> Consequently, I hereby open a straw poll for folks to indicate >whether or >> not they think that announcing a deprecation is sensible. >> >> Regards, >> >> Galen >> -- >> Galen Charlton >> Manager of Implementation >> Equinox Software, Inc. / The Open Source Experts >> email: gmc(a)esilibrary.com >> direct: +1 770-709-5581 >> cell: +1 404-984-4366 >> skype: gmcharlt >> web: http://www.esilibrary.com/ >> Supporting Koha and Evergreen: http://koha-community.org & >> http://evergreen-ils.org >> >> _______________________________________________ >> 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/ >>

1 0

3.14 / vm
by Samuel Desseaux 24 Sep '13

24 Sep '13

Hi, I've a question : As member of the team for the next release, i 've been elected as vm manager (and for the documentation).As it's a new role, I begin to work on it but i 'd like to know where this vm could be hosted and how to plan the release of the vm. I've vm for 3.12 but in french for the moment and could prepare vm for old releases. Best regards samuel

2 2

Queryparser : still experimental?
by Mathieu Saby 24 Sep '13

24 Sep '13

Hi I've never try to activate Queryparser, and I did not follow at all its implementation in Koha (shame!>:o ) So, could someone remind me if it is still "experimental"? Is there some case where activating it could be harmful? Is it planned to make its use mandatory one day and to suppress the syspref dedicated to it? Regards, M. Saby -- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby(a)univ-rennes2.fr

2 1

Voting for the Kohacon 2014 location
by Mirko 23 Sep '13

23 Sep '13

Dear Koha community, you can now vote for the location of the Kohacon 2014 conference. The survey requires your email address, and your IP address is kept until we have the final results. Please be nice and only vote once. Your option are Córdoba (Argentina) and Ibadan (Nigeria). A little information about the locations in question can be found here http://wiki.koha-community.org/wiki/KohaCon2014_Proposals You can vote at http://abunchofthings.net/limesurvey/index.php/952665/lang-en You can vote from now on until October 6, 23:59:59 UTC. -- Mirko

1 0

XML::Simple or YAML for read config files ?
by Zeno Tajoli 23 Sep '13

23 Sep '13

Hi to all, I have to define a configuration file for Koha. Which perl module do we want to prefer for config files ? YAML (like system prefences) or XML::Simple (like koha-conf.xml) ? Cheers Zeno Tajoli -- Dr. Zeno Tajoli Dipartimento Gestione delle Informazioni e della Conoscenza z.tajoli(a)cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate

2 3

Bot testing patches
by Chris Cormack 22 Sep '13

22 Sep '13

Hi all You may have noticed that there have been a bunch of updates from <gitbot(a)bugs.koha-community.org> to bugs in 'Needs Signoff' status. It is running through all bugs in that status, grabbing the patches and applying them, and changing the status if they don't apply clean. If people find this annoying I will turn it off. If people don't I will start on phase 2, which is making it run all the tests after applying the patches, and catch any fails. My idea is that everything in the 'Needs Signoff' should be passing tests and applying cleanly. Chris

5 14

Need advice for Bug 10758 - Show bibliographic information of deleted records in acquisitions
by Mathieu Saby 21 Sep '13

21 Sep '13

Hello Currently, when a biblio is deleted, it is moved to deletedbiblio (and biblioitems to deletedbiblioitems). Acquisition pages (basket.pl for example) are looking for bibliographic information about orders only in biblio and biblioitems table. So, if the biblio is deleted, the title cannot be found, while it is present in database, in deletedbiblio table. Same thing for statistics guided reports : if the biblio is deleted, the reports are unable to get information on the document. This is *very *annoying for us librarians, and taking into account the deleted records would be nice for us. So I am planning to make some patches to improve that: bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10758 Katrin Fisher has taken part to the discussion on this bug, but we are not sure of the best way of improving Koha's behavior. I suppose we could make a "union all" between (biblio and deletedbiblio) and (biblio and deletedbiblio) in the subs getting information about orders in C4::Acquisitions. ...BUT we cannot do that currently, because of the "ON DELETE SET NULL" constraint in table aqorders for biblio.biblionumber column (the biblionumber is deleted when the biblio is deleted...) So, I suppose we need to change the structure of aqorders - either by removing the foreign key from acqorders.biblionumber to biblio.biblionumber - or editing the constraint (I don't think it is possible) - or by creating a new column 'deletedbiblionumber" in acqorders I would prefer the 3d option (the "cleaner" for me, as I suppose removing foreign key is not good for integrity of DB), but I am very very far from being a database expert or a real developer. So, what is your opinion on that subject? Regards, M. Saby -- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby(a)univ-rennes2.fr

2 9

Create a new column in biblio table for opac visibiliy status
by Mathieu Saby 20 Sep '13

20 Sep '13

Hi I have a project about making more easy to hide/unhide records on the OPAC (without having to edit the record in cataloguing mode). http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9778 In the discussion with Fridolyn Somers, the idea of creating first a new column in biblio table for storing the "OPAC visibiliy" status appeared. It is not *stricty *needed but I imagine it could be used by other enhancements later. The issue is that there no field used universally in UNIMARC for storing the visibility information (for ex. in our library we have a non standard field for that, so our Zebra record.abs is specific for this point).:-( So to take advantage of this change, libraries (maybe only Unimarc libraries?) which will upgrade to 3.14 will need - to map their frameworks with the new field in sql database, so that Koha could know which MARC field is used to store the information. - then, to run a script - once for all - for updating this new field in sql database As it will imply manual operations after upgrade, I wanted to get the opinion of the RM fist. So, Galen, have you got some objections or comments? Mathieu Saby Rennes 2 university

2 4