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

DateTime::Format::MySQL
by Chris Nighswonger 24 May '12

24 May '12

Hi all, The QOTD work recently committed to master adds DateTime::Format::MySQL as a core dependency thereby extending DateTime objects to handle proper formatting of datetime strings for MySQL. While Koha::DateUtils will parse ISO formatted datetime strings, the POD notes that the module is intended to be a temporary aid to demystify DateTime foo while we are transitioning fully to DateTime: "Koha has historically only used dates not datetimes and been content to 40 handle these as strings. It also has confused formatting with actual dates 41 this is a temporary module for wrappers to hide the complexity of switch to DateTime" There are similar DateTime::Format::<db> plugins for Pg, Oracle, and friends which may be implemented in Koha as support for those db's is added. Basically DateTime::Format::MySQL will parse a correctly MySQL formatted datetime and return a DateTime object for your morphing pleasure. It will also format a DateTime object and return a MySQL datetime string. Read more here: http://tinyurl.com/br49o38 By moving away form a custom DateTime formatting module we reduce long term maintenance costs and issues as well as moving a step closer to dropping the temporary Koha::DateUtils. Kind Regards, Chris

1 0

Re: [Koha-devel] Print page - Firefox, etc
by Paul 23 May '12

23 May '12

At 02:01 PM 5/22/2012 -0400, Owen Leonard wrote: [snip] >Judging from the description and the timeline of Koha 3.6.1 I'm >guessing the bug is caused by my first fix for Bug 6291 which was >subsequently reverted in favor of a better fix. Thanks - what's the best way on a *production* server to revert the patch and install the better fix? I must admit to not fully understanding how git (or whatever is most appropriate) is setup, and after a look at bug 6291, there appear to be quite a few elements touched. In my sandbox, I once tried (unsuccessfully) to have two parallel but different versions of Koha so do not really want to try that on the production box. Best - Paul > -- Owen > >-- >Web Developer >Athens County Public Libraries >http://www.myacpl.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/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://UltraMarine.ca>, <http://AandC.org> and <http://MarDoc.ca>

2 1

KOCT pushed on contrib repo
by Paul Poulain 22 May '12

22 May '12

Hello, I just pushed a few minuts ago a patch with KOCT on the contrib repository (http://git.koha-community.org/gitweb/?p=contrib/global.git;a=summary) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

2 1

Print page - Firefox, etc
by Paul 22 May '12

22 May '12

Our cataloguers are having a local problem that I was unaware of. This is probably Koha bug 7199 which appears to be a tad inactive; I'd be happy to assist, but have no knowledge whatsoever of how browsers render CSS|templates for printing. Trying to "print page" after a staff screen listing such as <http://koha-admin/cgi-bin/koha/catalogue/search.pl?q=lambert%2C+andrew> (the page itself is perfect) gives an oddball output with the "Results" and "Location" columns squeezed down to very narrow columns on the right hand side of the page. The "check box" column (normally very narrow) expands to well over 50% of page width. This happens (for us at least) in Firefox (v. 12.0), Chrome (build 16.0), Safari (5.1) and MSIE (6.0 - we don't have anything more recent in our Win machine.) A quick review of "equivalent" OPAC search pages (rather than staff-admin) shows no problems. Koha 3.06.01.000, on Linux 2.6.38, Perl 5.010001, Apache 2.2.17, mysql Ver 14.14 Distrib 5.1.54, for debian-linux-gnu Thanks - Paul

2 1

Proposed QA Enhancements
by Chris Nighswonger 22 May '12

22 May '12

I am making two proposals that will help "tighten" up our QA procedures a bit in order to facilitate clarity and transparency in our patch submission/acceptance workflow. Currently the workflow is described in the wiki here: http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow#Steps 1. I propose that we modify step 5 to read: "The patch is checked and signed-off by the QA team member. Then the bug status is set to Passed QA" This will ensure that we have clarity that the patch was, indeed, touched by a member of the QA team, as well as increasing the accuracy of QA stats in git. 2. I propose that the RM be the QA of last resort. At present the stats show that the RM is doing the majority of the QA'ing. "Last resort" is a condition evoked by all members of the current QA team acknowledging that no one among them has the time, etc. to do QA on a particular patch the RM feels needs to be pushed OR by a bug remaining in the "Signed Off" status beyond a fixed time period of four weeks. This mechanism would address concerns of bug stagnation by allowing ample time for QA members to at least glance at a bug and determine of they do or do not have time to give to that bug as well as having a catch mechanism for bugs falling through w/o notice. Here are some statistics on sign-offs by the currently listed QA team for commits between the 3.6.0 and 3.8.0 tags: NOTE: 100% of our patches have the minimum required 1 sign-off by any community member Total commits: 1086 Sign-offs by QA Team members: Marcel de Rooy - 43 Jonathan Druart - 5 Paul Poulain - 538 Ian Walls - 25 Total commits w/sign-off by a QA team member: 611 OR 56.3% Total commits w/sign-off by RM: 538 OR 49.5% Total commits w/sign-off by non-RM QA member: 73 OR 6.7% These figures reasonably agree with the stats posted here: http://blog.bigballofwax.co.nz/2012/04/24/statistics-for-koha-3-8-0/ You may reproduce them on your local git repo master branch by using variations of the following: git log --grep="^Signed-off-by: <regexp>" --no-merges --oneline 52c666edce42..5c32a9f811d | wc -l Lets have some discussion on the two proposals above, and I'll put them on the agenda for the next IRC meeting to be voted on. Kind Regards, Chris

6 5

Re: [Koha-devel] Public IP for Koha
by Tim O'brien 21 May '12

21 May '12

Hi, I manage to intall koha 3.6. My institution has four branch libraries and i wanted to use public IP so that the other three branches can access the system. I am thinking of using public IP for these purpose. Kindly advice me: the risks and if there are better options. Regards, O'brien

3 2

Koha Calendar
by Elliott Davis 16 May '12

16 May '12

As I'm sure everybody running master has realized, bug 5549 introduced a new module Koha::Calendar. After digging around in the module I realized that the table special_holidays had separate columns for year, month, and date. I am wondering what the rationale is behind this decision. If it was simply I preference I would like to propose that we move it to replace the 3 current columns with a timestamp so that the calendar can take advantage of setting open and closed hours and fining for hourly based items accordingly. Elliott Davis Library Systems Analyst Robert R. Muntz Library [Description: Telephone]903.565.5542<tel:903.565.5542> [Description: Envelope]tdavis(a)uttyler.edu [Description: Chrome]http://library.uttyler.edu<http://library.uttyler.edu/>

2 1

Re: [Koha-devel] Multi-Lingual SQL & User Defined Parameters
by Karam Qubsi 16 May '12

16 May '12

Hi Dear Mr Massoud , Dear all, I think this will be very helpful for the people who don't want to use the English interface in Koha , and as you say when we finish translating koha 3.8 to Arabic ( very soon inshaallah) , we will have problems with the people who want to use koha in Arabic and english in the same time e.g: May be some Arab librarian prefer to use koha English interface for the staff client , and in the case that we've used the translated sql files (that your company provided it to us) for the marc21 the Arab librarian who want to use the English interface will have a problem because all the staff client will be in english except for the marc records and if we use the English version of the marc21 sql files the problem will be that the Arab librarian who will use the Arabic interface will see the marc fields in english so if we want to use arabic interface we have to use arabic sql files for marc is it possible to make something like armarc as we have normarc in the SQL structure ?! it's not a standard we don't really have 'armarc' and it is not a solution so the library chose its Marc flavor and all the librarian in that library will be forced to use this armarc , but will help to make the installation of the translated Arabic marc more easier and for the preferences description is included in the po files but the preferences still in English (the main term ) maybe the best solution is to make all the strings in koha included in the po files I don't have deep technical background but this will be more flexible for koha users all over the world for other languages not only for the Arabic language wish you will be able to do that for all the koha community :) thanks a lot for you Mr Massoud and thanks you all in Koha community for helping us :D Karam Qubsi Koha Arab Translating Team http://koha.wikibrary.org/ Wikibrary for Arab Librarians http://wikibrary.org > Date: Wed, 16 May 2012 09:00:57 +0300 > From: Massoud Alshareef <massoud(a)kwareict.com> > Subject: [Koha-translate] Multi-Lingual SQL & User Defined Parameters > To: koha-devel(a)lists.katipo.co.nz, koha(a)lists.katipo.co.nz, > koha-translate(a)lists.koha-community.org > Message-ID: > <CAMp2hxbU3fzajsQjgd-hou-RiPLmJ7y8Wf3XU=k2=5W15pPzmQ(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hello, > > I have asked a question about two years ago about when we can have Koha > support of Multi-Lingual SQL files (used for marc21/Auth fields description > in the Staff client) and Multi-Lingual users defined parameters (used for > describing items/ libraries & groups/ locations/ patrons categories/ etc), > and the answer from Koha development then was that it is > under consideration but not in the development pipelines yet, as it will > require some re-structuring in Koha system databases and controls. That > means, Koha will remain a single language in these areas. > > With Koha 3.6 release, I noticed the inclusion of "Spanish translation for > SQL files" in the INTERNATIONALIZATION enhancement section. Does this mean > that Spanish Koha, or any non-English Koha, now has both Spanish and > English SQL files, where Koha users can switch between more than one > language when, for instance, editing marc records in the staff client ? > > Koha Preferences description used to be in SQL files, which means a single > language prefers, and then moved into PO files format with 3.2 release (I > think) and thus Preferences became multi-lingual since then. > > Thank you Koha development for elaborating on the issue of having a fully > bilingual Koha. > > BTW, Arabic Koha 3.8 is now on the fast-lanes translation speed to be > completed within 3-4 weeks. > See Arabic Koha 3.8 OPAC demo site on > http://176.34.184.60/cgi-bin/koha/opac-search.pl?q=%D8%B9%D9%84%D9%85 > > Thanks > Massoud M. AlShareef, > > The world of achievement has always belonged to the optimist! > > KnowledgeWare Technologies > (P.O. Box 230-312) > Riyadh 11321, Saudi Arabia > Cel: +966 505 307 267 > massoud(a)kwareict.com >

2 1

sandbox system
by Paul Poulain 16 May '12

16 May '12

Hello koha-devel, I just pushed a few minuts ago the 1st version of the sandbox scripts I've developped and that is available to facilitate testing of Koha patches. You'll find everything, including some installation notes at http://git.koha-community.org/gitweb/?p=contrib/global.git;a=summary (git clone git://git.koha-community.org/contrib/global.git contrib, in the sandbox directory) PS: if you want to improve my scripts, you're welcomed ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0

Multi-Lingual SQL & User Defined Parameters
by Massoud Alshareef 16 May '12

16 May '12

Hello, I have asked a question about two years ago about when we can have Koha support of Multi-Lingual SQL files (used for marc21/Auth fields description in the Staff client) and Multi-Lingual users defined parameters (used for describing items/ libraries & groups/ locations/ patrons categories/ etc), and the answer from Koha development then was that it is under consideration but not in the development pipelines yet, as it will require some re-structuring in Koha system databases and controls. That means, Koha will remain a single language in these areas. With Koha 3.6 release, I noticed the inclusion of "Spanish translation for SQL files" in the INTERNATIONALIZATION enhancement section. Does this mean that Spanish Koha, or any non-English Koha, now has both Spanish and English SQL files, where Koha users can switch between more than one language when, for instance, editing marc records in the staff client ? Koha Preferences description used to be in SQL files, which means a single language prefers, and then moved into PO files format with 3.2 release (I think) and thus Preferences became multi-lingual since then. Thank you Koha development for elaborating on the issue of having a fully bilingual Koha. BTW, Arabic Koha 3.8 is now on the fast-lanes translation speed to be completed within 3-4 weeks. See Arabic Koha 3.8 OPAC demo site on http://176.34.184.60/cgi-bin/koha/opac-search.pl?q=%D8%B9%D9%84%D9%85 Thanks Massoud M. AlShareef, The world of achievement has always belonged to the optimist! KnowledgeWare Technologies (P.O. Box 230-312) Riyadh 11321, Saudi Arabia Cel: +966 505 307 267 massoud(a)kwareict.com

1 0