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

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

INSTALL.debian is outdated
by Jonathan Druart 27 Nov '16

27 Nov '16

2015-11-11 22:37 GMT+00:00 Robin Sheat <robin(a)catalyst.net.nz>: > Aparrish schreef op wo 11-11-2015 om 08:13 [-0700]: >> I followed the official instructions: >> http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=INSTALL.debian;hb… > > We need to delete those, they're from 2012 and are super out of date. Shall we 1) delete them, 2)replace them with the content of the wiki page or 3) just put a link to the wiki page?

12 23

Introduce the use of Grunt or Gulp?
by Owen Leonard 13 Oct '16

13 Oct '16

I would very much like to start using some kind of build tool for front-end assets in Koha. The ones I've encountered are Grunt and Gulp: Grunt: http://gruntjs.com/ Gulp: http://gulpjs.com/ I have some experience with Grunt, and have heard good things about Gulp. Has anyone else used either in their non-Koha projects? Adopting them would introduce a little more complexity to the process of making client-side changes to Koha, and to be honest I'm not sure of the right way to incorporate the tools into our workflow. What I see as the advantages: - Automatic linting, minification, and concatenation of CSS and JS - Potentially, automatic compression of images and contruction of image sprites - Overall performance improvements from the above Disadvantages: A new process to learn for those wanting to contribute front-end modifications. A new set of dependencies for front-end developers (Node.js etc). If there is interest I'd be happy to submit a patch introducing the process to the OPAC as a demonstration. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

10 22

How do we find consensus on interface changes?
by Owen Leonard 06 Oct '16

06 Oct '16

Do we need a procedure for getting consensus on Koha interface changes? I'm thinking about this issue in part because of a couple of interface changes I've been working on. One for Bug 16421: Move hold edit actions into dropdown menu https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16421 (screenshot: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51111) ...and another for Bug 11375: Patron permission names are untranslatable https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11375 (screenshot: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51847) When proposing a change like that should there be a more inclusive process than getting one sign-off and one QA approval? If so, how do we decide what kind of changes require wider approval? How do we solicit opinions from a wider audience? Or is the process working well as-is? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

9 15

Koha::Object[s] improvements - call for discussions
by Jonathan Druart 11 Aug '16

11 Aug '16

Hi devs, At the KohaCon16 some of us have briefly talked about the limitations of Koha::Object[s] we encounter when implementing new modules. Koha::Object[s] has been pushed to master less than 18 months ago and we already have more than 30 classes using it. It permits to uniformise our way to code, use powerful objects and is very easy for refactoring. I have been moving code from C4 to the Koha namespace and it's very handy to just have to write a concise module and automatically have the basic methods (CRUD and more). However it seems that we need to clearly define what we need in a near future and adapt it quickly if it's needed. = Rooms for Improvement = There are 3 main rooms for improvement: - DBIx::Class basic methods - DBIx::Class relationship accesses - Koha::Objects vs DBIx::Class objects == DBIx::Class basic methods == If you want to access a method provided by DBIx::Class, like ->store, ->delete, ->is_changed, we need to create a silly method which just calls the same method on the DBIx::Class object. For instance, let's take Koha::Objects->is_changed sub is_changed { my ( $self, @columns ) = @_; return $self->_result()->is_changed(@columns); } Possible solution: It would be possible to modify our AUTOLOAD method and check if it's a DBIX::Class method. If it is a valid one, let's call it, otherwise carp something. == DBIx::Class relationships == >From a Koha::Objects, the relationships provided by DBIx::Class will not be automatically generated. For instance, from a virtual shelf, you will not have access to the items on the shelf. You will have to create a method which will call the DBIx::Class relevant relationship. sub get_contents { my ( $self ) = @_; my $contents = $self->{_result}->virtualshelfcontents; return $contents; } This piece of code adds a get_contents method to Koha::Virtualshelf and call the virtualshelfcontents relationship created by DBIx::Class. Note that this is finally good here, it is better to call have a get_contents method than virtualshelfcontents. But we may prefer to redefine it in the schema file (Koha::Schema::Result::Virtualshelve). Possible solution: Same as previously, it would be possible to modify our AUTOLOAD method and check if it's a valid relationship. == Koha::Objects vs DBIX::Class objects == We'd like to always manipulate the same kind of objects, to avoid confusion when reading the code. At the moment we already manipulate 2 different entities: hashref from C4 and objects from Koha::Object. It's confusing and not so easy to manage in the code. To add flexibility we have added a Koha::Object->unblessed method to transform the object to an hashref, it's not ideal but it ease the transition. Anyway, from a Koha::Object if you want to retrieve data linked to this object, you would like to get a Koha::Object object base, not a DBIx::Class object base. If we continue with the previous example, we will need to modify get_contents like this: sub get_contents { my ( $self ) = @_; my $rs = $self->{_result}->virtualshelfcontents; my $contents = Koha::Virtualshelfcontents->_new_from_dbic( $rs ); return $contents; } Basically ->new_from_dbic will just create an empty Koha::Virtualshelfcontents object and set the internal resultset. No query or extra processing should be done here. I do not know if the changes suggested (and already implemented in some areas and patches in the queue) is consistent. It's not very elegant to read, but it looks safe on the performance side, despite the encapsulation problem we could see at first glance. = Concerns = == API == Some people raised concerns about the new API to lean. But finally we stick on DBIx::Class method names, so it should not be to hard to learn for new devs. And... the modules in the Koha namespace are much more easier to read/understand than the legacy code in C4. == ResultSet == It seems that writing the following is not obvious for everybody: # Create and store my $biblio = Koha::Biblio->new( { title => "a title", [other => $data] } ); $biblio->store; # Retrieve data my $biblio = Koha::Biblios->find( $biblionumber ); my $biblio = Koha::Biblios->search( { title => "a title" }); # Access relationship my $items = $biblio->items; warn ref( $items ); # Koha::Items warn ref( $items->first ); # Koha::Item This looks very easy to read for me, feel free to suggest something else. = A complete example = At the moment, the more complete example in master (and 16.05) is the Koha::Virtualshelf and Koha::Virtualshelves modules. It includes several search methods, overwrite of the store method and some complex methods as well as complete test coverage (t/db_dependent/Virtualshelves.t) = Alternatives = If you think you can provide an alternative or an idea to improve/replace our Koha::Object[s] implementation, do not hesitate, I would be glad to review or even implement it! If you want to discuss one of these point, add a new one, or have a specific question, please answer this email. We could talk about that during the next dev meeting as well. Cheers, Jonathan

4 5

RFC: Retiring of the koha-patches mailing list
by Jesse 13 Jul '16

13 Jul '16

Traffic on the koha-patches mailing list has been slowly dying off over the past several years, and at this point it's almost entirely unused. Bugzilla now gives us the workflow that the patches mailing list was a part of. Does anyone have any strong objections to shutting down the mailing list? While any of us can, of course, unsubscribe, I don't feel there's a good reason to keep it running. -- Jesse Weaver

8 8

Using the file upload feature for more customization
by Owen Leonard 13 Jul '16

13 Jul '16

Now that there is a generic file upload tool, could that be used to offer more customization options in areas where file selections are used? I'm imagining a system where you define upload categories: CSS, image, audio file, XSLT. Then wherever a setting allows you to select a file in that category Koha would list your uploaded files as options. Currently it's a problem for libraries who want to define their own set of item type icons or load a separate CSS file: Where does the file go? I just wanted to throw that idea out there in case it sounded interesting to someone. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

4 5

Extending the action_logs table
by Tomas Cohen Arazi 07 Jul '16

07 Jul '16

Hi everyone, I started to work on logging Holds actions (Bug 14642). One of the interesting things to log is the context in which those actions take place (OPAC, staff, CLI scripts). Do u have any opinion on the best way to do it besides just adding an 'interface' column or smth similar? Regards -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

5 6

libsearch-elasticsearch-perl and liblog-any-perl
by Stefano Bargioni 01 Jul '16

01 Jul '16

Hi, I'd like to show Koha running with Elasticsearch at the incoming KohaLa's Symposium in Lyon. I have a Debian 8.5 + Koha 16.05 virtual machine. Following [1] and [2], I installed Elasticsearch. However, installing related Perl modules, I get this error (translated from Italian): libsearch-elasticsearch-perl depends on liblog-any-perl (>= 1.02); but: installed version of liblog-any-perl is 0.15-1. There is something about liblog-any-perl >0.15-1 in [3], but it seems not stable. Any help? Thx. Stefano [1] https://wiki.koha-community.org/wiki/Elasticsearch [2] http://debian.koha-community.org/koha/otherthings/ [3] https://packages.debian.org/search?keywords=liblog-any-perl

6 12

Hackfest in Marseille in October
by Paul Poulain 30 Jun '16

30 Jun '16

Hello everyone, A reminder/invitation : the hackfest will take place in Marseille, oct 10th-14th. More details on our blog: http://www.biblibre.com/en/blog/october-hackfest-marseille ! Please register :D -- 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