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

items.wthdrawn
by Galen Charlton 27 Nov '07

27 Nov '07

Hi, Alas, the withdrawn status column in the items table is called 'wthdrawn', not 'withdrawn'. This is observed in most places in the code except for (as I discovered) some of the MARC 21 framework initialization SQL. I'm going to replace references to 'items.withdrawn' with 'items.wthdrawn'. While I would prefer to spell the column correctly, sticking with 'wthdrawn' for now affects rather fewer files. I'll wait for 3.2 to rename the column. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709

1 0

Fix for NPL intranet template bug
by Nicholas van Rheede van Oudtshoorn 27 Nov '07

27 Nov '07

Hello, There's a rather irritating CSS bug with the NPL acqui.simple/addbiblio.tmpl template. When you click on the tab numbers, the selected tab is made visible, and all other tabs made invisible. Unfortunately, (at least in the latest Firefox!), the invisible tabs still occupy the same space they would if they were visible. I'm not sure if it's the right fix, but the following version of the active() javascript function (inside the template file) seems to fix it (Added lines are bolded). Apologies that this isn't a patch - I never got around to figuring out how to use the *patch* command properly! Nicholas van Oudtshoorn function active(numlayer) { for (i=0; i <= 9 ; i++ ) { ong = i+"XX"; link = "link"+i; if (numlayer==i) { with(document){ if (document.getElementById(ong)){ document.getElementById (ong).style.visibility="visible"; * document.getElementById (ong).style.height="auto";* } if(document.getElementById(link)){ document.getElementById (link).style.color="#000066"; document.getElementById (link).style.backgroundColor="#FFFFCC"; } } } else { with(document){ if (document.getElementById(ong)){ document.getElementById (ong).style.visibility="hidden"; * document.getElementById (ong).style.height="0";* } if (document.getElementById(link)) { document.getElementById (link).style.color="#669999"; document.getElementById (link).style.backgroundColor="#D8DEB8"; } } } } }

1 0

Issues for README.txt and Makefile.PL
by Thomas Dukleth 26 Nov '07

26 Nov '07

README.txt and Makefile.PL for Koha 3.0 needs a number of significant fixes and corrections. As I was preparing some proposed fixes, Joshua Ferraro informed me that there are various pending fixes from a few people. Some of the pending fixes will not be pushed up to the Koha git repository because they conflict with other more complete fixes. Galen Charlton has committed some fixes which have yet to be pushed up to the main repository. Galen's fixes may resolve at least some of the issues which I have had. Galen is actively working on these issues so I raise the issues that I had originally proposed to commit so that they may be considered for non-conflicting incorporation if they have not already been fully considered. Some issues follow. Please comment and add any additional issues. 1. README.TXT PROBLEMS. 1.1. LACK OF OPERATING SYSTEM DISTRIBUTION SPECIFIC INSTRUCTIONS. Ideally, the installation would work seamlessly on every operating system distribution which Koha supports. However, we know that seamless installation is not going to happen until the time is available for building a complete set of Koha packages for various operating system distributions. README.txt lacks direction to operating system distribution specific information and otherwise undistributed packages. I have had to rely upon one and perhaps now two supplementary binary packages for Debian to allow me to install Perl modules, which may not be critical to using Koha but are certainly good to have. Vincent Danjean has some supplementary Debian packages at http://www-id.imag.fr/Laboratoire/Membres/Danjean_Vincent/deb.html and MJ Ray has some at http://serene.ttllp.co.uk/~mjr/ . At some point, these should be placed in repository for apt to use. There seem to be problems building Barcode::Code12 8 on many platforms which is a dependency of the needed PDF::Reuse::Barcode which the binary Debian package from Vincent solved for me. There have been problems building Barcode::Code128 on many operating systems and platforms throughout its release history. See reports from CPAN testers such as this one for the current version, http://www.nntp.perl.org/group/perl.cpan.testers/2007/07/msg544810.html . I also have a dependency issue which I have not yet completely investigated for building XML::LibXSLT 1.6.3. Maybe keeping version 1.6.2 for now will not be a problem. 1.2. CORRECT PATHNAMES IN COMMANDS. Any pathnames in commands should at least match the default pathnames created by Makefile.PL. Perhaps Makefile.PL should build the necessary commands to run with the correct pathnames during make install or make install should also create a script to run the commands after make install. 1.3. ENVIRONMENT VARIABLES. Possibly conflicting Koha release 2.2 environment variables should be unset or reset if that may be a potential problem for some. 1.4. SPECIFYING THE XML CONFIGURATION FILE OPTION FOR ZEBRA. The -c option is still given for zebrasrv which should long ago have been changed to -f for using an XML configuration file. 2. MAKEFILE.PL PROBLEMS. 2.1. PROBLEMS PREVENTING SUCCESSFUL MAKE. File globbing which captures directories builds a makefile which aborts with the following error when running make. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ERROR: Cannot copy 'installer/data/mysql/fr/mandatory' to '/usr/local/lib/cgi-bin/koha/installer/data/mysql/fr/mandatory': Is a directory !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! at -e line 1 make: *** [pm_to_blib] Error 21 Changing general file globbing from * to *.* for using the '.' in filenames can fix that problem. However, that solution is not robust if files are not in *.* form and at least needs a specific correction for .htaccess as the only file which does not match the pattern. 2.2. INSTALLATION DIRECTORY PROBLEMS. Default installation directories are not what they should be. If the task of resolving these issues has been left to Galen, I am not going to take the full time to make a detailed list, however, some special attention should be given to general principles. The defaults do not put directories where they should be in multiple cases. 2.2.1. CONFLICT BETWEEN PL_FILES AND MAP_TREE. I believe that Galen has a fix for the problem where map_tree values had been overwriting PL_FILES values. 2.2.2. ZEBRA DIRECTORY LOCATIONS. The case of Zebra is especially problematic. The treatment of the Zebra directories does not follow important principles. Currently, configuration and data directories for Zebra are in the same location. 2.2.2.1. SEGREGATION OF CONFIGURATION AND DATA. Configuration files should be segregated from data files for easy and distinct management. Configuration files are traditionally stored in /etc or some equivalent such as /usr/local/etc. Data files are usually stored in /var or some equivalent such as /var/local. Configuration information in some form of /etc can be reasonably compact for storage and backup. Data in some form of /var may be quite large and require its own disc storage for all of what it needs to contain and as use develops it may grow significantly over time. 2.2.2.2. MISSING DIRECTORY. One additional issue is of special importance. The main Zebra temporary directory is not created on installation. 2.3. INSTALLATION FILE OWNERSHIP. The webserver user should be read and ownership of the necessary files should be changed to the webserver user when running make install. 2.4. CONFIGURATION FILES CONTENT. 2.4.1. GENERAL CONFIGURATION FILE PROBLEMS. Configuration file pathnames do not match either the default pathnames or the actually installed pathnames. 2.4.2. KOHA-HTTPD.CONF. Using the ScriptAlias directives is considered a security vulnerability. Alias directives, rewrite rules or some other more secure method should be substituted for ScriptAlias directives. Directory options should be specified in advance 2.4.3. KOHA-CONF.XML. The Koha administrator username and password should be written to the file according to what is specified. 2.4.4. LANGUAGE SPECIFIC CONFIGURATION FILES. Language specific Zebra configuration files are missing from the Zebra configuration directories. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783

4 5

Digital Signature Implementation
by arnab 26 Nov '07

26 Nov '07

Dear All, I'm using Koha227 on windows platform. I'm working on a customization module of patron authentication using Digital Signature. Patron could search books and send requisition to the librarian. At the time of the issue, the patron has to give his/her password. The information regarding the book, patron id etc will be converted into a message digest and using a Digital Signature algorithm, would be stored in the database. In future if the patron denies accepting the book, this will be used to very the patron authentication. So, far I'm not able to install the module required for the implementation of digital signature. Should I go for implementing the Crypt::DSA module?? if so how should this module be installed. thanx Arnab -- View this message in context: http://www.nabble.com/Digital-Signature-Implementation-tf4872852.html#a1394… Sent from the Koha - Dev mailing list archive at Nabble.com.

1 0

Internationalising Koha frameworks
by Thomas Dukleth 26 Nov '07

26 Nov '07

Do you use MARC 21 in a language other than English? Do you use UNIMARC in a language other than French or English? Do you use a MARC variant other than MARC 21 or UNIMARC? If you have any language specific or MARC variant specific Koha frameworks for sharing, please contact me on or off the list. LibLime has asked me to prepare whatever MARC frameworks I can obtain for use in the forthcoming version of Koha 3.0. Share yours so that others do not need to do redundant work. [MARC frameworks are either bibliographic or authorities frameworks and go by various names in Koha depending upon how you access them. In the system administration intranet interface, they are identified as Biblio framework (MARC structure) for bibliographic frameworks or Thesaurus structure for authorities. In the installation directories, they have names such as structure_def.sql for bibliographic frameworks or authorities_normal_marc.sql for authorities.] I will supply very simple instructions for exporting your frameworks from your SQL database if you need such assistance. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783

1 0

How to start play with pre-Koha 3.0?
by Serhij Dubyk Сергі й Дубик 23 Nov '07

23 Nov '07

I am interested to install Koha 3.0 CVS to start translate it into native language (large work), test it and look about possibility to apply my patches 2.2.9 Think that necessary to begin with getting from CVS. How to do it correctly? Through a search I found such 3 variants: 1) cvs -d:pserver:anonymous@cvs.sv.gnu.org:/sources/koha login cvs -z3 -d:pserver:anonymous@cvs.sv.gnu.org:/sources/koha co . 2) cvs -d:pserver:anonymous@cvs.sv.gnu.org:/sources/koha login cvs -z3 -d:pserver:anonymous@cvs.sv.gnu.org:/sources/koha co . 3) git clone git://git.koha.org/pub/scm/koha.git kohaclone Also please tell shortly about depositarys of Koha (CVS, git ...) With kind regards Serhij Dubyk (Ukraine) -- View this message in context: http://www.nabble.com/How-to-start-play-with-pre-Koha-3.0--tf4857763.html#a… Sent from the Koha - Dev mailing list archive at Nabble.com.

2 2

OPAC default stylesheet (owen 1st)
by Paul POULAIN 22 Nov '07

22 Nov '07

Hi all (and mainly owen) Owen has removed the default stylesheet in opac : before last night commits, if the opaccolorstylesheet syspref cas empty, it was the nice opac.css that was choosen by default. Shouldn't we reintroduce this behaviour, to avoid having a black and white opac by default? note : the sysprefs loaded at install stage don't contain opac.css, so the page is really black and white. -- Paul POULAIN BibLibre SARL Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

2 1

marc2dc (Dublin Core support)
by Paul POULAIN 20 Nov '07

20 Nov '07

Hello world, I just wanted to point that, afaik, the marc2dc tools one can find in cpan are only MARC21 compliant. They do silly things for UNIMARC. I've seen some commits about that, to let the user export or view the catalogue in Dublin Core format. This won't work at all for us. And we don't intend to make that work in the next weeks, as it's purely a new feature. Our wish would be to remove that feature for instance. Anyway, you MUST remember that before adding any new feature: check what it does for UNIMARC guys. PS : - isn't it time to create a stable and an unstable branch in git ? and deal only with bugfixes for stable (dc is, obviously, an improvement) - I ask for a chat meeting to discuss of next weeks plans. -- Paul POULAIN BibLibre SARL Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

2 1

Thoughts for discussion concerning muliti-dbms approach to koha
by Chris Nighswonger 20 Nov '07

20 Nov '07

Hi all, I have been putting some thought into the best approach for moving koha to a multi-dbms application and wanted to throw out a few of these thoughts hoping to get a discussion started with the aim to form a roadmap as this will most likely require some fairly major refactoring of code. (Not trying to "take charge" here, just trying to get momentum built up. :-) 1. This migration should probably begin by bringing all current SQL in koha into compliance as far as possible with ANSI SQL 1999 which it appears most rdbms support. (This may be debatable, I am not widely versed on dbms's) Note: I think that it will not be possible to implement pure ANSI SQL due to different approaches by different dbms's in handling table, constraint, etc. creation. But it should be possible to bring queries, inserts, etc. into some high level of compliance. 2. Once koha is ANSI SQL 1999 compliant, we need to/will have identified irreconcilable differences between dbms's koha would like to support (MySQL, PostgreSQL, and Oracle are currently on the table afaik). I *think* most of these issues will fall into one of two catagories: a. Differences in how the basic db structure is created. (ie. kohastructure.sql) It appears to me that different files will have to be maintained for each dbms structure. (ie. MySQL incorporates secondary keys while in PostgreSQL indexes must be used for the same effect, etc.) b. Differences which allow exploitation of a particular dbms strength. It may be that these types of things could be handled by separate modules for each supported dbms with selective includes based on the db_scheme setting koha-conf.xml or perhaps using stored proceedures/functions with a common nomenclature called from the code or <insert other approaches here>.... 3. Begin porting current code. Here, I suggest that the port be approached with the goal of ensuring that MySQL support *always* works as the port goes forward. This may be idealistic and/or unrealistic. When I did work on the webinstaller to add PostgreSQL, I set as my priority to not break the MySQL portion. This should permit a high level of compatibility with the current production installs on a forward moving basis. (ie. changes are fairly transparent) If multi-dbms mechanisms can be coded to work with MySQL, then they *should* work for the addition of any number 'x' dmbs as the appropriate ports are made for each. If it is modular enough, once the core code is ported, we should be able to add any dbms with minimal disturbances to the core. So.... thoughts, critiques, discussion, etc...? -- Chris Nighswonger Faculty Member Network & Systems Director Foundations Bible College & Seminary www.foundations.edu www.fbcradio.org

4 3

Advanced search Queries in Nozebra mode, via Nozebra table, queriying column named 'indexname', returning __RAW__ and failing in Search.pm
by Ignacio 20 Nov '07

20 Nov '07

Hello, this is Ignacio, new to the excellent Koha, prepared to put my hands on.. I'm working with koha-3.00.00.005 (debian etch, perl 5.8.8, ran in apache 2 via mod_perl) and after configuring searches in noZebra mode I'm having some problems to patch C4::Search to make it correctly parse and return advanced queries. I'm stuck with advanced search queries in Nozebra mode (via koha mysql's nozebra table), failing in Search.pm: The snippet of code that selects which value of column indexname for the advanced query in question is needed is given by: $left='title' if $left eq 'ti'; $left='author' if $left eq 'au'; $left='publisher' if $left eq 'pb'; $left='subject' if $left eq 'su'; $left='koha-Auth-Number' if $left eq 'an'; $left='keyword' if $left eq 'kw'; .. The problem seems to appear when you find that this column, in my mysql tables koha installation, seems single and only valued __RAW__, so searches result in no rows. Is there anyway to change this behaviour of avoiding this everlasting __RAW__ or is this the expected behavior and there is some other configuration/version problem? Thanks, Ignacio Javier

3 4