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

New feature in HEAD (Koha NoZebra)
by Paul POULAIN 04 May '07

04 May '07

Hello world, I'm really proud to announce that Koha 3.0 No Zebra is on CVS. It's an optionnal feature to have Koha 3.0 without having indexdata zebra. Zebra is hard to setup & configure, so it will be a good thing for smaller libraries. I'll explain briefly how it works, on this mail and more deeply on the wiki. Brifely : - install Koha 3.0 (CVS head) and fill your database. Or update from an existing 2.2 - run misc/migration_tools/rebuild_nozebra.pl That script will : - set a specific systempreference (NoZebra) - define NoZebraIndexes systempref, that contains index definition. UNIMARC default definition is done, a MARC21 guy will do it easily. - create the needed table (nozebra) - populate it Once the script has run : - you can do CCL searches as usuall, but Koha will issue a specific SQL build. Seems i've succeeded to have AND / OR / NOT support, as well as "". So title="two towers' NOT author='tolkien' should work well - when you edit biblios, the SQL indexes are updated as well. Full compatibility with "Koha Zebra" is achieved by having only 3 specific entries in 2 packages : the API of Zebra & NoZebra Koha are strictly the same. Really. My tests show it's much musch faster than Koha 2.2 way of storing & indexing. I'll write on the wiki the limits of the NoZebra stuff & how you can/will choose between Zebra and NoZebra. Enjoy. -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19

1 0

translating Koha
by Karen Myers 04 May '07

04 May '07

Good morning I am working with libraries in East Timor and am very interested in translating Koha into the local language of Tetun. I think it could have great applications in Timor which has seen an explosion of new libraries that are running on the smell of an oily rag. Am I correct in understanding that I need to translate the opac-tmpl and intranet-tpml pot files only or is there more involved? I am using Koha on Windows at this stage but I assume the translation process is similar for Windows or Linux? I have read through the translating docs from the koha website but any other insights or help would be appreciated. Karen Myers _________________________________________________________________ Advertisement: Communication evolved. Hilarious clips on messsaging here. http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=763&refer…

2 1

bugzilla daily mail (for chris)
by Paul POULAIN 30 Apr '07

30 Apr '07

Hello chris, I recieve every day a mail with all my pending bugs on bugzilla. atm, the list is quite long, because it contains everything that is affected to me. So, I don't read the mail, & drop it to trash immediatly. Which is a shame, I agree. It would be much more usefull to have : - daily all BLO/CRI/MAJ/NOR bugs - weekly all bugs (including MIN/ENH) hope it's easy to do ;-) -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19

1 0

Roadmap [important]
by Paul POULAIN 27 Apr '07

27 Apr '07

Hello world, OK, i'll release 2.2.9 soon, based on rel_2_2_7 branch+some bugs ported from rel_2_2 (and only bugfixes) I've reviewed more than 100 commits on rel_2_2 branch, and am sure the stability of this branch is not that good enough to have a 2.2.9 release based on rel_2_2. On the other hand, 3-4 major bugfixes have been done, a release is needed. So i'll do it. But I want to speak of the next step. In the last weeks, we had : - HEAD : a lot of activity from hdl & me : code cleaning mainly. it should now be done. - dev_week : a lot of activity from ccfls (kyle & cindy) and some from libLime as well : some features backported from head (holidays) and a new feature ClubsAndServices, for some testing - rel_2_2 : a lot of activity from libLime : backported some features from head (holidays), and some new features (item level reserves, serials routing lists I think it is important that all commiters says what they are doing & when they think they will get enough stability to have a roadmap and a timeline. I also think it's important that all features added on 2.2 / dev_week were also added on head (or we could loose the features. That can be acceptable, but at least we will be aware of the fact, to avoid any bad surprise) Last but not least : I think we should speak of our organisation : it seems that rel_2_2 branch will become a new version with new features. I strongly think we should not call this version 2.2.10, but 2.4 or something like that, to point that it has new features & probably less stability. So we will need a 2.4RM. In the last 3 weeks, I could not get in touch with Joshua, or almost. I'm happy that business is going well for libLime, but, pls, try to find time to the community, we need everybody to work in the same direction, and know the direction we are going ;-) Our (hdl & me) position is clear : - I support 2.2.x branch as Release Maintainer - We work hard on head to achieve a 3.0 stable asap. code cleaning is done (although it's never done in fact. But all what had to be done is done), we plan to work on YUI asap, to have koha 3.0 stable for early Q3 Waiting for everybody thoughts, wishes & args ;-) -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19

3 2

items table
by Henri-Damien LAURENT 27 Apr '07

27 Apr '07

Hi, I am investigating in items table to see which data are used, useful and useless. I found that. Those information are meaningfull and useful : itemnumber biblionumber biblioitemnumber homebranch holdingbranch itemnotes location itemcallnumber itemlost notforloan timestamp reserves for reserve management dateaccessioned (boils down to creation date) If I understand correctly. The problem is that if MARC data is favoured, then we loose this value if not linked. wthdrawn is used in Circulation.pm to cancel an issue if set. renewals is used and updated in Circulation.pm. Maybe it could get into issues table. paidfor is used in FixAccountForLostAndReturned but usage is rather cryptic restricted (I cannot tell the difference with notforloan ?) itype ??? Those fields I propose to drop : binding (unknown use) onloan,issue_date are Already in issues + unknown use. issues (can be calculated from issues table) price,replacementprice (used in Overdues only for selection),replacementpricedate,booksellerid are account values which seem never to be used.

2 1

koha 2.2.9 roadmap
by Paul POULAIN 27 Apr '07

27 Apr '07

Hello all, The rel_2_2 CVS branch is still very active (from LibLime). A lot of new features have been added (some backported from head). Those new features are a problem for stability, and a few major problems have been solved in this branch. Thus, i've ported to the rel_2_2_7 branch all bugfixes & could release a 2.2.9 with them. Here is the list : * MAJOR bug in addbiblio and additem (Bug 1330). Previously, if you added a field to a biblio it would save it with the same tagorder as one of the items, and then editing an item would result in it being deleted. * fixed some SQL queries (mySQL5 errors. That does not mean koha 2.2.x is mySQL5 compliant, but that's some errors identified & fixed. Just expect koha 2.2.9 to work with fewer problem under mySQL5) * fixed a SQL typo in overdues fixing on return (database was not properly updated) * Solved a problem where a plugin value(fixed fields...) would be lost when editing a record * fixed a bug in expiry date calculation * ENH in z3950 search : adding a test in search to avoid a system error if the server returns an invalid error (can happend, depending on z3950 server) * ENH: Added finer ISBD parsing to allow subfield values to contain {}. * ENH: removed an extra (& useless although harmless) call to MARChtml2xml * ENH: if branch unknown from Koha, take it from userenv, instead of first-defined. This will set branch to users registration branch if not explicitly set. TRANSLATORS : i've translations for french, and spanish that are uptodate. The templates are the same as for 2.2.7/2.2.8 Let me know if you have other templates to add/update. what is the status of ukrainian translation (should be OK I think) -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19

1 0

(no subject)
by Chris Cormack 26 Apr '07

26 Apr '07

Hi All Paul Poulain reminded me on IRC the other night I hadn't done a post to the list about my recent change in work circumstances. For those of you who have been around Koha for a while you will know me as Chris from Katipo. Im now Chris from Liblime. Russel and Mason made the move with me as well. Heres the press release about it http://liblime.com/news-items/press-releases/liblime-to-acquire-katipo/ Just an explanation for any of you wondering who is this chris from liblime guy, I havent seen him on the lists before :) Chris -- Chris Cormack chris.cormack(a)liblime.com VP Research and Development www.liblime.com LibLime +64 21 542 131

1 0

Re: [Koha-cvs] koha/koha-tmpl/intranet-tmpl/npl/en/bull subscr... [rel_2_2]
by Paul POULAIN 26 Apr '07

26 Apr '07

Ryan Higgins a écrit : > CVSROOT: /sources/koha > Module name: koha > Branch: rel_2_2 > Changes by: Ryan Higgins <rych> 07/04/26 04:30:48 > > Modified files: > koha-tmpl/intranet-tmpl/npl/en/bull: subscription-detail.tmpl > serial-issues.tmpl > full-serial-issues.tmpl > > Log message: > small language changes >  > - Waited > + Waiting (cc: to koha-devel, anyone can give it's opinion) mmm... I won't argue on english quality, but : a "waited" serial means that it's not here, and is expected. A "waiting" item means (not serial) is here, but waiting for an event(being picked up by a patron, for a reserved item). Thus, in translations, it will be confusing to use "waiting" for 2 things. Could we choose a different word ? Is "expected" acceptable ? -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19

1 0

Members : Code Cleaning
by Henri-Damien LAURENT 25 Apr '07

25 Apr '07

* Bornamesearch and GuarantornameSearch => SearchMember * GetMember, borrdata,getguarantordata => GetMember with a change in signature. * borrdata2 => GetBorrowerIssuesAndFines * GetMemberDetails No changes. * calcexpirydate =>GetExpiryDate * modmember => ModMember * newmember => AddMember * borrissues => GetPendingIssues * allissues => GetAllIssues * GetMembeReregistration => ExtendMemberSubscriptionTo * getboracctrecord =>GetMemberAccountRecords no longer takes env * GetBorrowersTitles => GetTitles * findguarantees => GetGuarantees * DeleteBorrower => MoveMemberToDeleted (move member data to deletedborrowers) And DelMember (delete member) * deletemembercompletely => DelMember * GetBorrowersFromSurname => GetMembersFromSurname * citycaracteristiques => GetCities * GetBorNotifyAcctRecord now takes borrnumber, and $notifyid and no longer env, param. * GetFlagsAndBranchFromBorrower is deleted.

1 0

code cleaning of Reserves.pm
by Paul POULAIN 24 Apr '07

24 Apr '07

* GlobalCancel : renammed to ModReserveCancelAll * OtherReserves : renamed to GetOtherReserves * MinusPriority : renamed to ModReserveMinusPriority and SQL improvement: 2 nested SQL read/update that could be done in 1 step * SetWaitingStatus : renamed to ModReserveStatus * GetReservations and FindReserves merged, API changed and resulting sub is GetReserves * GetFirstReserveDateFromItem removed (mered into GetReserves improved to return the branchcode that was the only field missing) * splitting GetReserves in 3 different sub : one for each parameter. Depending on the parameter (biblionumber / itemnumber / borrowernumber), the GetReserves sub returned differents things (2 var, 1 array ...) that is silly & hard to read. Splitting in 3 subs is not the most efficient, but it's more readable. Later, we could maybe merge them again by having a common returned result, but i'm not sure it would be possible * CountReservesFromBorrower renamed to GetReserveCount * CheckReserves : No change (see question below) * CancelReserve : name unchanged (it's not a reserve deletion, so I think DelReserve is wrong) * FillReserve renamed to ModReserveFill and variable names changed internally * FixPriority renamed to _FixPriority (internal sub) * WaitingReserves renamed to ModReserveAffect, POD & cleaned * GetWaitingReserves : removed (merged in BetReservesFromBorrowernumber) * CalcHLTReserveFee : removed (hardcoded specific rules for HLT. Don't ask me to reintroduce them, I will disagree : we can't have specific hardcoded code in Koha) * GetNextAccountNumber : removed (unused) * UpdateReserve : renamed to ModReserve * findgroupreserve : renamed to _findgroupreserve (internal sub) * CreateReserve : renamed to AddReserve (& opac-reserve call fixed : a undef parameter useless) * CalcReserveFee : renamed to GetReserveFee * GetReserveTitle : removed (useless) * FindReservesInQueue : removed (copy of GetReservesFromBiblionumber) * CheckReserves : removed $barcode parameter (never used) QUESTION 1 : what is reservecontraint table done for ? does it work ? It seems that the table is filled only in Reserves.pm, CreateReserve, only if constraint='o' or 'e' (dunno what it means). In the code, contraint seems to be possibly 'a', but I don't know how it can occur. QUESTION 2 : could someone explain exactly how reserves work (internally). I'm not sure i've got all cases. CONCLUSION : i'm not fully happy with this cleaning. I think a second tour could/should be done, mainly in Modxxx sub, as I think we could have a fewer number of subs. But I won't do it. -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19

1 0