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

RFC 3.2: Autogeneration of Koha UML diagrams
by Zeno Tajoli 03 Sep '08

03 Sep '08

Hi to all, from first day of October 2008 CILEA is going to support a project about Koha as student stage (followd by me). We want to improve tecnical documentation about Koha 3.0 (I hope to have a stable release for october !!). Starting from perl scripts avaible from internet we want to develop a script that read Koha API (C4 dir) and write a .xmi file with an UML rappresentation of classes, methods and usage of methods. In fact a work like this is possible only if API are written in a precise standard of coding. It thimk it s , as I know. But this is also a good check. We will report all problems we found, to be fixed in 3.2 We also write complete E-R diagrams for Koha DB and a specific document for every table But now the .xmi file in fact needs to be sligthy different for every UML tool. We can work with two Open source tool, ArgoUML and Umbrello We can usa also Rational Rose (the biggest commercial tool for UML). Which tool do you prefer ? If you think it is a useful project, I will insert it into RFCs for Koha 3.2 <http://wiki.koha.org/doku.php?id=en:development:rfcs3.2> Bye Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)

4 5

RFC: Advanced patron search
by Danny Bouman 02 Sep '08

02 Sep '08

"Problem The ability is needed to search for patrons on many different fields, including email address, street address, phone number, etc. Using additional patron attributes is not a viable solution as it would require a tremendous amount of duplicate data on all fields that would need to be searchable. Possible Solution #1 Create a standard search API that functions for both circulation and patron searches and supports the ability to search on many different fields. Possible Solution #2 Create a member search API that supports the ability to search for patrons on many different fields. Technical Notes System preference should exist for what patron fields are able to be searchedWhen a Staff member clicks on the Patron menu item, they should immediately be taken to the advanced search screen, which could exist below the browse by last name. This display would be in a similar format to what Staff see when they click on the Search menu item.Patron Attribute types that are able to be searched should appear in the advanced search. http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_advancedpatro… Any thoughts, questions, or comments? -- Danny Bouman Web Programmer Howard County Central Library 10375 Little Patuxent Parkway Columbia, MD 21044 410.313.7924

3 3

Status of koha.org on Plone
by Joshua Ferraro 02 Sep '08

02 Sep '08

Hi folks, Well, September's here and I've still not been able to find the time to pull together a new koha.org site based on Plone; too many other priorities have gotten in the way. I still have it on my list and I'm optimistic that I should be able to turn something around in the next couple weeks, so please give me until Sept 15th to have something up and running with some basic content and a proposed workflow for authoriship, review, translation, etc. Sorry for the delays. Cheers, Josh -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

1 0

Python MySQLdb question
by Rick Welykochy 02 Sep '08

02 Sep '08

I know this is a bit far fetched but I am hunting for any hints anywhere. I have a script written in python that manipulates data (i.e. reads and writes tables) just fine for Koha/2.2.9 databases. This is using python + MySQLdb. But when I access Koha/3 tables, things are differnt. Reads are fine, i.e. I can select and read tables. But writes silently fail, i.e. all inserts are silently discarded. This is very weird behaviour for python, since it normally raises an exception if there are *any* problems in the db module. I am putting it down to differences between the Koha/2.2.9 tables and the Koha/3.0 tables. The only differences I can see are the charset used, i.e. Latin-1 vs utf8. Any ideas? cheers rickw -- ________________________________________________________________ Rick Welykochy || Praxis Services || Internet Driving Instructor Do you realise that in forty years we'll have thousands of old ladies running around with tattoos and rap music will be the golden oldies? -- Maxine

2 2

RFC 3.2 - turn on warnings
by Galen Charlton 30 Aug '08

30 Aug '08

Hi, Perl's warnings pragma is the cheapest way to find bugs. We already use the strict pragma; now it's time to add warnings. More importantly, it's time to review the messages produced by the warnings pragma and fix the underlying issues. To reiterate, this RFC has two goals: turning on warnings, and fixing all warnings thus reported. Doing the first without the second will simply cause Apache logs to overflow. Ideally, all Perl scripts and modules should have warnings enabled by the time 3.2 is released. I propose the following steps to implement this: 1. Update the coding guidelines to require 'use strict' and 'use warnings'. 2. For any new scripts and modules, require 'use warnings'. Since Koha (per Makefile.PL) requires at least Perl 5.6.1, the 'use warnings' pragma should be used instead of -w. 3. Systematically go through and turn on warnings for each script and module. 4. Unsystematically turn on warnings. I.e., whenever you patch a particular script, consider following up with a separate patch to turn on warnings. I suggest a separate patch because turning on warnings is not enough; you should run the script through its paces and fix any problems reported by the warnings pragma. For modules in C4, note that this can be a big commitment: turning on warnings means testing every function and method. 5. Create a standing blocker bug for 3.2 for adding "use warnings". 6. "no warnings" should not be used absent a detailed comment explaining why warnings should be turned off within a block and why it is not possible to change the code to avoid the warning. It _might_ be acceptable for temporary use while turning on warnings in a big module This RFC can also be found at http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_turn_on_warni… Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709 skype: gmcharlt

6 14

RFC 3.2 : guided reports improved
by Paul POULAIN 30 Aug '08

30 Aug '08

(http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_guided_reports) Guided reports are great. However, they are fully hardcoded SQL atm. There's no possibilities to have parameters that are fixed at run time. That would be usefull, for example, when you want to build a report that runs between a date range, or on a given branch or itemtype. for example, a tool to let a given branch see what they added in the catalogue could be : SELECT biblio,author FROM biblio LEFT JOIN items USING(biblionumber) WHERE items.homebranch=XXX This RFC suggest to add some improvements to be able to specify XXX at runtime. - A simple solution could be to have a specific syntax to say "enter value here". For example : ??? - A better sotution could be to have the syntax + a label to display to the patron. For example : ???Enter branch code??? that would display "Enter branch code : _______" in the <form> - The best solution would be to have a list where applicable (branch, itemtype...). The 2 first are easy to code, the 3rd could be tricky. but undoubtfully usefull ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08

7 10

Opac search results rss link working?
by Michael Hafen 29 Aug '08

29 Aug '08

Is it me, or is it Firefox? I couldn't get the rss feed to work in firefox. I had to fiddle a bit before I even had the option of subscribing, firefox doesn't like ' '. I didn't try beyond that because Firefox didn't give me any information beyond that, just feed failed to load. Any response on this topic would be much appreciated.

2 1

RFC: Melded system preferences page
by Jesse Weaver 28 Aug '08

28 Aug '08

Currently, to change the value of system preferences in Koha, you must click find the system preference, then click on it to edit it. The patches at http://arwen.metavore.com/~jpw/melded_sysprefs/ allow you to edit system preferences directly from the main screen; you should only need the edit link to change the type or options for a system preference.

1 0

Koha 2 & 3 on the same Server
by zang＠zang.co.za 28 Aug '08

28 Aug '08

Can someone please advise if it is possible to run Koha 2.2.9 and Koha 3 on the same Debian Linux Server? If possible, how to go about installing? The current Server is running Koha 2.2.9, but we need to run Koha 3 as well. Any advice will be appreciated.

2 1

Base template language for 3.1 (was: Standardised US English Translation)
by Galen Charlton 27 Aug '08

27 Aug '08

Hi, On Wed, Apr 23, 2008 at 6:56 AM, Joshua Ferraro <jmf(a)liblime.com> wrote: > On Tue, Apr 22, 2008 at 5:10 PM, <russ(a)russandsarah.gen.nz> wrote: >> I am happy to help out with standardising the language used in the default >> Koha install to that of the dictionary everyone agreed on. >> >> It would be easiest for me to do this using Kartouche at >> translate.koha.org, because then I can see how many strings still need to >> be translated and I can do it from anywhere. > Unfortunately, it's a bit more complicated that that. If we replace > all instances > of Catalogue with Catalog, all 28 translations of Koha will need to have their > PO files updated. I've identified a few words and variations that I > _think_ cover > almost all the en-GB/en-US/en-FR issues in the 3.0 version, and I can run a > search and replace against the codebase to update them. Here's what I came > up with: > > organisation authorised catalogue cataloguing Owen recently submitted a patch to implement this change: http://lists.koha.org/pipermail/koha-patches/2008-August/001620.html Based on the conversation in April, I believe that we have a general agreement that we'll adopt en_US and the ODLIS dictionary (http://lu.com/odlis/index.cfm) as the base template language. In turn, interested parties can prepare additional English localizations, including en_NZ, en_GB, en_AU, en_US_public, en_US_academic, etc. If there are any serious objections to this, speak now. Therefore, I propose to accept Owen's patch. For the convenience of the translators, I can also prepare a patch to update the existing PO files. Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709 skype: gmcharlt

3 2