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

Module MARC::Record doesn't set well lenght in leader.
by Zeno Tajoli 29 Sep '13

29 Sep '13

Hi to all, I have a problem with creating marc21 records with module MARC::Record I create marc records from reading a text file, but the module doesn't set a correct lenght in the leader. So same subfields are cutted and I loose data inside subfiels and inside indicator. An example of problematic record: DB<10> x $record 0 MARC::Record=HASH(0x53904f8) '_fields' => ARRAY(0x5471fa8) 0 MARC::Field=HASH(0x54694b8) '_data' => 328 '_is_control_field' => 1 '_tag' => 001 '_warnings' => ARRAY(0x53bb8d8) empty array 1 MARC::Field=HASH(0x545ea10) '_data' => 'IT-RoAPU' '_is_control_field' => 1 '_tag' => 003 '_warnings' => ARRAY(0x545df00) empty array 2 MARC::Field=HASH(0x5460d78) '_data' => 20130929162908.0 '_is_control_field' => 1 '_tag' => 005 '_warnings' => ARRAY(0x592ee28) empty array [...] 15 MARC::Field=HASH(0x546b1a8) '_ind1' => 0 '_ind2' => 0 '_is_control_field' => 0 '_subfields' => ARRAY(0x541c940) 0 'a' 1 'Biblia.' 2 'p' 3 'V.T.' 4 'p' 5 'Qohélet' 6 'x' 7 'Commenti.' 8 9 9 171552 '_tag' => 630 '_warnings' => ARRAY(0x5465538) empty array 16 MARC::Field=HASH(0x5465a18) '_ind1' => ' ' '_ind2' => ' ' '_is_control_field' => 0 '_subfields' => ARRAY(0x5466cd0) 0 'a' 1 'Biblia.' 2 'p' 3 'V.T.' 4 'p' 5 'Qohélet.' 6 'l' 7 'Inglese.' 8 'f' 9 1988. 10 9 11 '_tag' => 240 '_warnings' => ARRAY(0x5477168) empty array 17 MARC::Field=HASH(0x5462fa8) '_ind1' => ' ' '_ind2' => ' ' '_is_control_field' => 0 '_subfields' => ARRAY(0x541eb38) 0 'a' 1 'IT-RoAP' '_tag' => 850 '_warnings' => ARRAY(0x5931948) empty array 18 MARC::Field=HASH(0x5469788) '_ind1' => ' ' '_ind2' => ' ' '_is_control_field' => 0 '_subfields' => ARRAY(0x5472170) 0 'c' 1 32 '_tag' => 999 '_warnings' => ARRAY(0x54693f8) empty array '_leader' => '00859nam a2200265 i 4500' '_warnings' => ARRAY(0x53682b0) 0 'Invalid record length in record 324: Leader says 00859 bytes but it\'s actually 861' 1 'field does not end in end of field character in tag 630 in record 324' 2 'field does not end in end of field character in tag 240 in record 324' 3 "Invalid indicators \"\c^02\" forced to blanks in record 324 for tag 240\cJ" 4 'field does not end in end of field character in tag 850 in record 324' 5 "Invalid indicators \"3\c^ \" forced to blanks in record 324 for tag 850\cJ" 6 'field does not end in end of field character in tag 999 in record 324' 7 "Invalid indicators \"U\c^ \" forced to blanks in record 324 for tag 999\cJ" In fact indicator of tag 240 are wrong (the correct values are '02'); -- Dr. Zeno Tajoli Dipartimento Gestione delle Informazioni e della Conoscenza z.tajoli(a)cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate

1 0

Clone an item
by Paul 27 Sep '13

27 Sep '13

I seem to remember that there was a discussion | bug | request to be able to clone an item during the staff edit process, in the same manner that a biblio can be cloned. Could someone please point me in the right direction of any work that might already have been done on this? Many tnx and best regards Paul

2 1

3.14 feature freeze notes
by Galen Charlton 25 Sep '13

25 Sep '13

Hi, Feature slush is imminent, as is feature freeze. Here are some notes on what I expect this to mean in practice. New Features -------------------- At this point, every bug that is in a state of passed QA, with exceptions I will name below, can provisionally be considered candidates for inclusion in Koha 3.14. Any new feature or enhancement patch that reaches passed QA by 23:59 on September 25, 2013 in my time zone (UTC-7) can likewise be provisional candidates. By provisional candidate I mean the following: [1] I will review it and either push it or give an opportunity for the submitter to address QA concerns. [2] My presumption will be that the feature end up getting pushed to master. [3] This NOT, however, a guarantee that it will get pushed -- my primary concern is a stable master; if we run out of time (by which I mean the end of hackfest at KohaCon) to address quality concerns on any given patch, it's not going in. Any patches that reach passed QA between September 26, 2013 and 23:59 on October 3, 2013 will also be considered provisional candidates for release, but are more likely to be held over for post-3.14 if there are problems. In other words, enhancements that reach slush will get looked at first. Exceptions ---------------- I am giving the following enhancement bugs special dispensation to be considered for inclusion even if they miss the freeze date by a bit: * 8798: Add the use of DBIx::Class * 10565: Add a "Patron List" feature for storing and manipulating collections of patrons (depends on DBIx::Class) * 10493: Add renewal script (depends on DBIx::Class) * 10309: New OPAC theme based on Bootstrap * Bugs related to adding DOM indexing support for UNIMARC * Bugs related to LDAP * Debian packaging improvements * Bugs related to the GRS-1 deprecation announcements being discussed * Bugs related to making QueryParser enabled by default, also being discussed The following bugs currently in a passed QA state will get pushed in some form, but I will be submitting a counter-patch: 8190: Add a logging module to Koha The following bugs currently in passed QA may not get pushed: 9854: Add 'ttf-dejavu*' packages to debian/control file, for label printing (bug 8375) -- the patch for this does not stand on its own until patches for related bugs are ready 7167: updatedatabase improvements -- I have spent a *lot* of time mulling this one over -- and in the final analysis, in my opinion it would add far too much complexity to solve a problem that can be addressed by our agreeing never to fail a patch purely on the basis of a resolvable merge conflict. To my knowledge, that is current the case. The current practice of linearly applied schema changes, while not the most flexible possible system, has been /very/ successful for the average Koha user, and I am very hesitant to risk regressions during upgrade. Organizations who deploy new developments in advance of their release -- and I appreciate why and how that happens -- ultimately must take responsibility for managing schema updates for their customers. However, I do have thoughts on a possible compromise that can provide a /simple/ mechanism to specify that specific updates are to be bypassed. I'll will think on this some more and update the bug by the end of the week. But sneak preview -- if we make it possible for DBrevs to be identified by both the version number and a tag (such as the bug number, for example), it would be simple to set up a mechanism for somebody to inject DBrevs in advance of a release without having to know the version number that ultimately gets assigned, then have updatedatabase.pl bypass reapplying those specific revisions -- without having any effect on a stock Koha database. This wouldn't solve everything, if the schema and data changes for the update get modified during the patch review process, but that's part of the risk anybody assumes by running in advance of master. Bugfixes ------------- There is no specific freeze date for bugfixes except the constraints imposed by string freeze at the end of October. However, I cannot guarantee that all bugfixes that reach passed QA before release will make it in; patches that stabilize new enhancements will take precedence during the month of October. 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

3 3

Coding guidelines and Plack
by Marcel de Rooy 25 Sep '13

25 Sep '13

Hi all, Had a discussion with Jonathan on bug 9032 about the use of variables and requirements for Plack. Our coding guidelines do not yet mention Plack. Should we add a PERL rule that prohibits defining lexical variables (my $var) at the outermost block (file level) ? Is it also needed to move script subroutines to module level? Other requirements? It would be beneficial if we could update the coding guidelines accordingly.. Thanks, Marcel

3 3

880 filed
by Morsy, Amal 25 Sep '13

25 Sep '13

Hallo, We have several books in Arabic and other languages that we like it to be displayed in its original language in the catalog. We would like to make a use of 880 filed. We want to enter the author name in English and display it in the other language as well and make it searchable My question is how I can add 880 filed to the 20000 records in the library without risking losing any of the existing data? And if I want to add 880 filed to a new framework for the future cataloging, how can I do that? I appreciate if there are tutorials about these issues. Thank you in advance for your help Amal -- * Amal Morsy * *Library Director * 202-785-1141 ext. 222 <http://www.mei.edu/> Providing non-partisan, expert information and analysis on the Middle East. For additional information please visit www.mei.edu | 1761 N STREET NW, WASHINGTON, D.C. 20036-2882 <https://twitter.com/MiddleEastInst>@MiddleEastInst<https://twitter.com/MiddleEastInst> | <https://www.facebook.com/middleeastinstitute> Middle East Institute<https://www.facebook.com/middleeastinstitute> | <http://www.mei.edu/feeds/analysis> MEI Analysis & Opinion<http://www.mei.edu/feeds/analysis> **

1 0

Re: [Koha-devel] Test Request
by Paul 25 Sep '13

25 Sep '13

At 09:37 AM 9/24/2013 -0700, Galen Charlton wrote: >Hi, > >On Tue, Sep 24, 2013 at 9:31 AM, Paul Poulain ><<mailto:paul.poulain@biblibre.com>paul.poulain(a)biblibre.com> wrote: >Overall, in public libraries, it's probably a rare situation, while in >an academic one, it's more common. > >We've at least one library that would love this feature ;-) > >Thanks, it is very helpful to know that there is at least one library >(beside's the patch submitter's) who would be interested. I'm also interested, but not certain that the scenario is identical. I'm looking for a way to hide some items from "not-logged-in" users (i.e. the great big public on the WWW), but allow our "logged-in-members" (WAN and LAN) to be able to find them. Best - Paul

2 1

writing a file on server from staff interface
by Mathieu Saby 25 Sep '13

25 Sep '13

Hi for my patch about facets, I currently have 2 problems : 1- how to put the file in /etc/ of installation directory (in discussion) 2- how to allow the perl script (from staff interface) to write or rewrite the yaml configuration file if a librarian decides to change some settings. If I do nothing special, YAML::DumpFile fails to (re)write the file, because - I suppose - the apache user does not have rights to access the server. So, for the moment, the only way I found to make my config file editable is "chmod 666". But I suppose it is not very safe... Do you know if there is a safer way to do that? How is managed for example for SolR configuration files? Regards Mathieu -- 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

5 8

Test Request
by Mark Tompsett 24 Sep '13

24 Sep '13

Greetings, Seeing as there is very little time left before the feature freeze, I was wondering someone could look at bugs 10900, 10895, and 10589. 10900 corrects a bunch of ugly scariness related to set_userenv in C4::Context. This allows 10895 to be tested on 10589. I realize that I should have put the test for 10589 on the same bug, but at the time, the 10589 was signed off. Sadly, I had to rebase, and all three need sign off. 10589 allows changing the scope of OpacHiddenItems based on Patron Category. For example, one category (let’s say cataloger) could search for hidden items in OPAC for just their branch, while another category (let’s say staff) could search for hidden items in OPAC across all branches, while another category (let’s say patrons) wouldn’t see any of the hidden items. This is configurable via two new system preferences PatronSingleBranch and PatronEveryBranch. GPML, Mark Tompsett

6 11

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