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

Not listed my question?
by Librarian Guide 11 Aug '17

11 Aug '17

Dear Admin, I have sent many times my questions and doubts to clarify on forum but none of them have been posted. Please let me know why it is so? -- With kind regards, ************************************ *Dhanwantari Prakash Tripathi* ************************************ *Assistant Librarian, Periodicals* Biju Patnaik Central Library <http://library.nitrkl.ac.in> National Institute of Technology <http://nitrkl.ac.in> Rourkela, Odisha - INDIA *- 769 008* *M - +91-8895296796* *U - www.dptripathi.in <http://www.dptripathi.in> * *YouTube - Librarian Guide <https://www.youtube.com/channel/UCqq2XkD5KKp5W7VrMJOsGhw>* ************************************

1 0

MARC frameworks in Koha
by Marcel de Rooy 10 Aug '17

10 Aug '17

Hi developers or librarians, If you are interested in say sorting search results or lists by publication date based on 260 and RDA 264, please read further. OR If you use varying kohafield mappings across your MARC frameworks. Say you connected biblio.copyrightdate to 260$c in framework A, but to 264$c in framework B. Bug 10306 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306) is aimed to resolve the issue of having the copyrightdate in two MARC fields. It allows you to have multiple mappings per kohafield. So you can connect 260c and 264c to copyrightdate. Current Koha allowed you to add the second mapping already in the frameworks, but it silently ignores one of the two. In finishing this development however, I got stuck at the following question: Should Koha really allow varying kohafield mappings per framework? In the above example the multiple mappings feature should resolve the need of having a different assignment for copyrightdate between framework A and B. Both could simply have two mappings for copyrightdate. Although Koha more or less allows you to add kohafield assignments per framework via the MARC frameworks, it does not really support kohafields per framework. (The Koha to MARC mappings tool in Administration does change the mappings in Default and copies them to other frameworks.) We have GetMarcFromKohaField calls in the codebase that do not pass a framework code. And when we process search results or import records, we do not have a framework code either. So in those cases Koha just uses the kohafield mappings from the Default framework, although you might have specified another mapping in the associated framework of a search result. I would propose now to make the decision that we only use one set of kohafield mappings (those from Default), and that we do no longer allow changes to kohafield mappings in the other frameworks. The possibility of adding multiple mappings per kohafield hopefully removes most objections to that approach as illustrated in the frameworks A and B example. I submitted my changes so far on the Bugzilla report. If we agree on Default as the authoritative framework for these mappings, I will still add code to change GetMarcFromKohaField calls etc. If you have stringent reasons for maintaining varying kohafield mappings per framework and your need for them cannot be resolved with multiple mappings, please respond and provide information about the fields you are mapping differently across your frameworks. Any other feedback is welcome too. Thanks, Marcel

4 8

Koha Developers IRC meeting reminder - Today August 9th, 22 UTC
by Jonathan Druart 09 Aug '17

09 Aug '17

Hi All, My apologies for late reminder, we have a Developers meeting in IRC scheduled for today at 22 UTC (in ~1hour) Local time/date conversion here: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+I… The agenda is here: *https://wiki.koha-community.org/wiki/Development_IRC_meeting_9_August_2017 <https://wiki.koha-community.org/wiki/Development_IRC_meeting_9_August_2017>* Please add any topics you wish to discuss to the agenda, or add yourself in to the apologies if you can't make it. Hope to see you all there! Nick^WJonathan

1 0

AUTO_INCREMENT fix - prevent data lost
by Jonathan Druart 09 Aug '17

09 Aug '17

Hi devs, Please review and test https://wiki.koha-community.org/wiki/DBMS_auto_increment_fix I have added a ref from the Koha on Debian wiki page https://wiki.koha-community.org/wiki/Koha_on_Debian#Further_Configuration It sounds like I should add it somewhere more visible, but do not find where, any ideas? See also bug 18931 where I would like to add a warning on the about page if data are corrupted. Please review quickly, that way we can share the tips on the general mailing list. Cheers, Jonathan

8 18

ES6 usage in the staff client
by Jesse 09 Aug '17

09 Aug '17

As part of my work with Preact (and previous work with React), I've been unsure what to do about these libraries' enthusiasm for ES6. If you're not familiar, ES6 (or ES2015) is a recent, major update to the JavaScript standard, and brings in a number of improvements to the language. Many of these make small parts of JS development a bit more pleasant, but the most relevant addition is native class support. These built-in classes have been embraced by a lot of modern JS libraries, including Preact. The commonly accepted way to write code in this libraries depends on support for classes, either from the browser itself or a transpiler like Babel. To use Preact, we have two options: * Use ES6 classes. This will work in Firefox 45+ (which includes two ESR releases), Chrome 42+, Edge and Safari 9 [1][2]. I believe this is a very reasonable set of browsers, for the staff client. * Use a shim for ES3 support (see [3] for an example of how this might work). This can be done, but locks us to an older and less-used way of developing on Preact/React. I strongly prefer the first option, but would like your feedback. [1] http://kangax.github.io/compat-table/es6/#test-class (Check "show obsolete platforms", and get ready for your browser to slow down.) [2] http://caniuse.com/#feat=es6-class (This is pessimistic; FF has had support since version 45.) [3] https://github.com/developit/preact-in-es3/blob/master/index.js -- Jesse Weaver

8 11

Expected behaviour if itemtype does not exist
by Jonathan Druart 08 Aug '17

08 Aug '17

Hi devs, Since bug 17843 I get errors if the item type (items.itype or biblioitems.itemtype depending on the pref item_level_itypes) does not exist as an item type (table itemtypes, filled by Administration › Item types administration). The error (Can't call method "translated_description" on an undefined value) appears because we call a method on an undefined value. As this is a configuration issue (right?) I think we should add an alert from the updatedatabase.pl script, then a warning on the about page. Would that be enough or should we handle the problematic case anyway (i.e. call the method only if the item type exists in DB)? Cheers, Jonathan

3 4

Re: [Koha-devel] MARC frameworks in Koha (Hector Castro)
by Hector Castro 07 Aug '17

07 Aug '17

Hi Marcel On 7 August 2017 at 08:06, <koha-devel-request(a)lists.koha-community.org> wrote: > > I would propose now to make the decision that we only use one set of > kohafield mappings (those from Default), and that we do no longer allow > changes to kohafield mappings in the other frameworks. > The possibility of adding multiple mappings per kohafield hopefully > removes most objections to that approach as illustrated in the frameworks A > and B example. > > End of Koha-devel Digest, Vol 141, Issue 7 > ****************************************** > Good job. +1 I think that it is necessary to allow mapings from Koha to MARC mapping and avoid the changes in frameworks. Librarians' needs go in the way to data presented in the screen, i.e., they got in their catalogs a mix between RDA records and AACR records, for example, if a librarian start to catalog records in RDA and she or he goes to Acquisition Module, when places an order, the screen does not show the publication data because biblio.copyrightdate is empty. This happen in a few modules where presentation on screen not uses XSLT. I think this only happen in MARC 21 records As a librarian I am excited to know that this is fixed. Greetings -- Atte, Héctor Eduardo Castro Avalos

1 0

QA Tools
by Marcel de Rooy 03 Aug '17

03 Aug '17

Hi Jonathan, Got this warning from qa tools: POD coverage was greater before, try perl -MPod::Coverage=PackageName -e666 Looking at the code in qa tools, I come across: } elsif ( $before->{rating} > $after->{rating} ) { # Not sure we can reach this @diff = ('POD coverage was greater before, try perl -MPod::Coverage=PackageName -e666'); When I removed a routine from C4::Biblio, this happens: Before C4::Biblio has a Pod::Coverage rating of 0.96078431372549 After C4::Biblio has a Pod::Coverage rating of 0.96 If we have N subroutines and 2 without POD and a score of 2/N, and I remove one routine, we will now have 2 / N - 1. This means that the before > after test does not work here. Raises a false negative. Marcel

1 0

KohaDevbox | Remote debugging
by Tomas Cohen Arazi 02 Aug '17

02 Aug '17

Hi everyone, Last week (or so) I posted bug 18964 [1]. It introduces option switches to the koha-plack script allowing it to run in debug mode, starting a debugging session on a remote IDE/editor supporting the xdebug protocol. It is submitted and NSO. In the meantime I've added a koha-plack-debug script to KohaDevBox. It's the same script from the bug, different name. In order to use it, some new configuration entries need to be set in user.yml: - remote_debugger: true - remote_debugger_location: "host:port" - remote_debugger_key: "your_ide_key" host:port is set to localhost:9000 by default in this setup. And the IDE key is the empty string ''. Tweak as needed, but keep the surrounding double quotes. A new alias has been added: - plack_debug_start it will fail to run if Plack is already running for the configured instance. Make sure you run this before: vagrant$ sudo koha-plack --stop kohadev vagrant$ plack_debug_start Find me or Lari or Olli on IRC if you have doubts. Enjoy! [1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18964 -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

1 0

Results of the poll "Ready to help the Koha community?"
by Jonathan Druart 02 Aug '17

02 Aug '17

Hello everybody, I have published the results of the poll, launched at the beginning of the 17.11 development release cycle. https://koha-community.org/answers-of-the-poll-ready-to-help-the-koha-commu… There are the results, and a list of remarks and notes that people did. I tried to give them answers. I let you comment, if you have something to add. Regards, Jonathan

2 1