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

2.2 branch strategic question
by Paul POULAIN 15 Sep '05

15 Sep '05

Hi, 2.2.4 should be here soon, & i'm wondering what to do with releases. Let me explain my questions... I've released a new minor version every quarter. Each contains : - some bugfixes - some new features. Those new features didn't change the DB for 2.2.1, 2.2.2 and 2.2.3, and will change a little the DB for 2.2.4. With the 3.0 version announced for 2006Q1 (end of...), i'm not sure it would be the best solution to continue releasing 2.2.x with new features. Here is a list of pro and cons i've found. Feel free to add some of them. pro : - new features are always nice to have before next major release - some of them are very important and could be considered as bugfixes (like leader support in 2.2.4, for example) cons : - installing a new version every quarter is too much work - learning what is in a new version every quarter is too much work, libraries are missing new features ! - it's too much work to synch 2.2 and head with new feature. That won't be easier with new head work ! - new features means ... new bugs ! so, I suggest, after your reactions, feel free to say if we need a poll in koha & koha-fr mailing lists or decide. but i really have no preferred opinion. Maybe a little feeling that we could just release bugfixes in 2.2 branch. But not sure. Note that some features were requested by some customers and requires to be quickly written in order to deploy Koha, so i think I was right -from my point of view- until now ! -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

3 2

Koha 2.2.4 translations
by Paul POULAIN 15 Sep '05

15 Sep '05

Hi, i've uploaded uptodate version of the .po files for all languages available. You will find the updated files here : http://cvs.sourceforge.net/viewcvs.py/koha/koha/misc/translator/po/ (updated daily only, should appear tomorrow) The 2.2.4 should be released on Friday, 23. You can send me updated translation files directly if you can't commit them on CVS. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

1 0

about leader management
by Paul POULAIN 13 Sep '05

13 Sep '05

hi, i've read on irc that joshua could not store leader in biblio modif (with cvs rel_2_2) It works for me, so i'm wondering if you didn't forgot to create a field '000' with a subfield '@' and activate it in your framework ? (I use 000 and @ to have a field and a subfield, as it's easier -from far- in the code, although it may be a little bit tricky to find without help ;-) ) I also have seen the reservoir problem. That may be the same origin I suspect (but untested => pls confirm or not) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

2 1

question about
by Spencer Anspach 13 Sep '05

13 Sep '05

In C4::Biblio.pm, the subroutine MARCmarc2kohaOneField is passed the current statement handle ($sth) but never uses it. Can anyone tell me if this is a left-over artifact of an earlier functionality? Or an area of future development? The reason I ask is that I've implemented non-filing indicators locally (it is far from elegant, but it works, barely), but in order to do so I needed the database handle ($dbh) in that subroutine. The only subroutine that calls it (MARCmarc2koha) has $dbh, so it wasn't any problem to change the first parameter being passed from $sth to $dbh, but I wondered if that was something that was going to break future planned functionality. I tried to read through the revision notes and comments, but I didn't see anything that pertained. Also, that subroutine isn't exported and the comments indicate it should only be used by MARCmarc2koha (within Biblio.pm), so it seemed pretty self-contained and a managable modification. Thanks, Spencer -- Spencer M. Anspach, Library Systems Analyst/Programmer Library Information Technology, Indiana University Library E456 phone: (812) 856-5318 Bloomington, IN 47405 fax: (812) 856-4979 sanspach(a)indiana.edu pager: (812) 335-7403

2 3

Barcode Printing Problems
by Joshua Ferraro 13 Sep '05

13 Sep '05

Hi all, Is anyone using barcode printing on a production system? I recently tried to get them working and although I can get it to produce barcodes there are two problems: 1. The file that's exported has an extension of .pl ... this means that most OSes can't determine that it's a PDF by default. What's the best way to export it as a useful filename and extension? 2. The barcodes that are generated have leading zeros and one zero after the barcode. So they're almost right, but in their current form aren't really useful (don't scan correctly). Anyone else experiencing the same problems? Any solutions out there? Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

6 5

Koha Statuses and MARC?
by Joshua Ferraro 13 Sep '05

13 Sep '05

Paul et al, In Paul's proposed scheme for item statuses, the items.notforloan field is linked to MARC field 942$k and then an authorized value is set for that field (defined by the library). Before we invest too much development energy on this idea I'd like to question whether it's even a good idea to store status information in the MARC record, especially we we move toward using Zebra to store our textual (MARC) database. Stephen and I spoke earlier today and he's got me thinking that maybe it's not such a good idea to store statuses in MARC. MARC wasn't really designed for anything but the static record information. It's ill-suited for transactional based data such as statuses. I propose that for Koha 3.0 we create a new field in the Koha tables called 'items.status'. items.status can be a numeric value and have a set of library-defined authorized values. We can then add a framework for setting those values that a library must setup when they install the system. For instance, it should be possible to set Koha to automatically set an items status to 'in transit' when an item is on reserve to a patron in a branch other than the holdingbranch (when the item is returned) and 'waiting' when it arrives and is scanned. But the goal would be to make this a setting that the library could define when setting Koha up, a set of 'status rules'. Comments, suggestions, volunteers? Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

2 1

The future of Koha (some ideas and thoughts) [IMPORTANT] (I hope) and [LONG] (not so)
by Paul POULAIN 13 Sep '05

13 Sep '05

Hello all, I was in Paris yesterday (what does not justify a mail on koha-devel, I agree ;-) ), and was thinking to the future of Koha in the TGV (3hours to do 850km !) I suddenly realized that, with the architecture we are working on for Koha 3.0, we were on the way to develop what I call "Koha-Suite". I mean in Koha 3.0, we will have : * a web portal. (Our actual OPAC) * a tool to store large datas (Zebra) * all ILS features. We spoke once to have RSS feeds in OPAC, I'm sure that's a great idea that could be implemented quite easily in Koha and highly improve OPAC use & utility. Once rss feeds will be availabe in OPAC, we could consider Koha interfaced with any CMS, as most actual CMS are providing rss feeds. We could imagine "rss boxes" in main page as well as in opac-user page. Just a suggestion for instance, it's not done (except in some argentinian code, iirc) So we have a software in 4 parts. All of them can be modularized to consider we have 4 differents bricks that can be foundation of a complete document-oriented-suite. What we could add later is : * a brick to manage electronic document (like thesis & internal production of the user-company) Internal docs as well as OpenArchive harvester. * a brick to index external sources, that could be sorted & analyzed to do a knowledge DB (in french, it's "veille technologique", that I don't know how to translate. I mean : a tool that automatically check some databases daily, compute summaries on accurate documents, and send them to users) Of course, the 2 later bricks won't be written in a day or 2. Not even in this month. And probably not for 3.0 But I'm sure (& hope you will confirm) that it's the way to go. If confirmed, then Koha developpers will have to write all 3.0 stuff with this goal in mind, on the long term. It means having a code structure modular enough to be able to install a brick without all the others. Just one technical proposal, about code organization : We could have, under koha-cvs, one directory for each brick : * /opac/ for web portal (yes, we already have it !!!) * /core/ for the common and core scripts (I think actual modules : parameters, reports and members) * /ils/ for ils part of Koha suite (I think actual acquisition, cataloguing, circulation, authorities) * /XXX/ for electronic docs management (new brick, does not exist yet) * /YYY/ for external source (KB) (new brick too) * The /C4/ directory contains every core Perl packages and will be a common tool, used by every brick, so it can stay on top level of CVS org. With such an architecture it would be easy to release specific packages, for "Koha ILS-only", "Koha KB-only", "Koha ILS and electronic doc management" ... I have created a little scheme to explain my idea (maybe a basis for a future marketing document ;-) ) You can find it on : http://___www___.paulpoulain.com/Koha_futur.pdf (remove the trailing ___ before and after www, I just want this link not to be indexed by google) Don't distribute this doc outside from this list for instance pls, it's my idea, not the Koha team decision ;-) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

6 12

some informations on item status
by Paul POULAIN 13 Sep '05

13 Sep '05

Hello, Following some IRC chat & joshua commits, here are some explanations about item status : "item status" covers 2 things : - what is automatically set - what is manually set what is automatically set => the position of the book regarding issuing. It means wether the book is on issue, waiting, or "available". There is no field the DB to store this : the issues table is searched everytime it's needed => the "on order" flag, that can be set only when there is no item for a given book, but an order placed on it (remember a book is immediatly created when you place an order, in MARC as well as in non-MARC DB) what is manually set => it's 3 different fields in items table : - notforloan - itemlost - wthdrawn Since Koha 1.x, all those fields have the following meaning : 0 means "no", and 1 means "yes". So notforloan=1 basically means item is not for loan and notforloan=0 means its not not for loan (= can be issued) In Koha 2.0, i've added a feature that works at least for notforloan and MARC=ON : you can define a list of authorized values that are integers and used in the MARC subfield that is mapped to items.notforloan. the rule being : 0 means "no" >1 means "yes". Thus, you can define why an item is "notforloan". Can be, for example "being repaired", or whatever you want. The consequence is that you can have notforloan meaning : 0 : available 1 : not for loan 2 : lost 3 : withdrawn 4 : being repaired 5 : ... and thus lost & wthdrawn fields are useless for me. HTH -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

2 2

Independed branch functions
by Owen Leonard 13 Sep '05

13 Sep '05

HDL, Can you give us all a summary of the new independent branch functions you've added recently? What kind of things does it allow and restrict? Thanks, Owen

2 1

Boolean operators in koha opac search
by Partha Mukhopadhyay 13 Sep '05

13 Sep '05

Dear friends, Does KOHA support Boolean (AND, OR, NOT), relational (>, >=,<,=<,=) and positional (NEAR and PROXIMITY) operators in OPAC search? I tried to combine two keywords with simple AND, OR and NOT operator. But it is not working. Is there any symble to indicate these operator such as & for AND, | for OR and ^ for NOT? These symbols (&, | , ^) are also not working for combined search. Help me.... Parthasarathi Mukhopadahyay VU, DLISc, India -- India.com free e-mail - www.india.com. Check out our value-added Premium features, such as an extra 20MB for mail storage, POP3, e-mail forwarding, and ads-free mailboxes!

2 1