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

KOHA version 3.0, my question is about the advantages of KOHA 4
by Christian Calle Jahuira 08 Jun '11

08 Jun '11

It is a pleasure to find KOHA community greatly strengthened. Write to La Paz Bolivia, I have implemented KOHA version 3.0, my question is about the advantages of KOHA 4 and LibLime, which presents differences. Atte -- Christian Jhonny Calle Jahuira TUTOR ELEARNING - UMSA Consultor Sistemas de Informacion de Bibliotecas de la UMSA Email: christianjcj(a)gmail.com Cel: 73017301 - 65151595

13 32

Koha More regarding local call number search/barcodes
by Linda Culberson 08 Jun '11

08 Jun '11

All, At Chris's suggestion, I'm moving this to the development list. It seems to me that Henri-Damien is correct in that exact would be better for the sn and bc indexes but that the phrase might work better for call numbers. Since I am very much a newbie at this, I'd like to hear from those more experienced about the best way to proceed. Do I need to put this discussion on bugzilla or just the outcome of the discussion when we're ready to proceed? We are very interested in contributing but don't want to create any problems when trying to fix something. Thanks, Linda On 1:59 PM, LAURENT Henri-Damien wrote: > Le 06/06/2011 20:57, Chris Cormack a Ã©crit : >> > On 7 June 2011 06:53, Linda Culberson<lculber(a)mdah.state.ms.us> wrote: >>> >> The problem, at least in 3.4, does exist, but changing the query from >>> >> sn,wrdl to sn,phr and bc,wrdl to bc,phr seems to fix it. >>> >> >>> >> But I'm still wondering if there are others - besides call numbers - >>> >> for which this applies. >>> >> >>> >> I apologize for the multiple emails. I should do more research before I >>> >> email. I'll try to keep quiet now. >>> >> >> > >> > Hi Linda >> > Multiple emails are fine, but perhaps this discussion is better on the >> > koha-devel list. >> > I think its not a new problem (i think 3.0.x up did this) but that >> > doesn't mean its right. >> > >> > I think phr for barcode, sn, etc makes more sense and I would >> > encourage you to widen the scope of your bug to include them. >> > The fix is simply changes in the template so should be relatively >> > straightforward to implement and would be a welcome fix for many >> > libraries I think. >> > >> > Chris > Well, it all depends on what you search, but ext could be really what > you are looking for. > With phr you could look for : > AAAA/BB > And find > AAAA/BB C > AAAA/BB D > or even > C AAAA/BB > where ext would match the exact subfield... > But one default for that is that you cannot search both ext and * afaik > (could be quite easy to test if anyone interested. In a yaz-client : > f @attr 4=1 @attr 6=3 @attr 5=2 "your callnumber" > ) > > and that ext search requires the completeness set to 1 on the index type > you use in default.idx ... Which is commonly the case when you use p... > Moreoved, consider that using p should not replace w indexing, but be added. > Since there are places in the code or in database settings where lcn can > be searched directly without using phr modifier. And if you donot have > indexed with word... Then the search will always fail which would be > worse than the problem it fixed. > Hope that helps. > -- Henri-Damien LAURENT -- Linda Culberson lculber(a)mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Fax: 601/576-6824

2 1

Global sign off day, 2011-06-15
by Magnus Enger 07 Jun '11

07 Jun '11

Dear all! (And sorry for cross posting... At least a little bit ;-) We had such great fun in Marseilles earlier this year, signing off patches, that I have been wondering if it would be possible to re-create some of that experience without incurring the costs of travel. I broached the subject on IRC earlier today and after the briefest and least democratic of processes, "we" decided to declare 15th June 2011 as a Global Sign Off Day: http://wiki.koha-community.org/wiki/Global_sign_off_day,_2011-06-15 The hope is that as many people as possible will be able to set aside as much other work as possible on this day, and concentrate on signing off patches, to reduce the queue of bugs that are currently waiting for sign-off (66 at this moment: http://bugs.koha-community.org/bugzilla3/buglist.cgi?bug_status=NEW&bug_sta…) We will try to visualise and document the progress that is made, to make it more fun and maybe even tickle the competitive instincts a little bit... ;-) And who knows, if this day is a success, maybe we could turn it into a regular tradition? * If you have not signed off on a patch before, now is the perfect time to do it! The more the merrier! The process is outlined here: http://wiki.koha-community.org/wiki/Sign_off_on_patches And there will be people on IRC that you can ask for help and guidance! Best regards, Magnus Enger * On the other hand, let's hope we can keep the queue as short as possible...

1 0

RFCs
by Nicole Engard 07 Jun '11

07 Jun '11

Hello developers, On looking at the wiki I see that the 3.4 RFCs have some things that didn't make it in to 3.4 and the 3.6 RFCs page is empty. We should probably move the devs that didn't make it to 3.4 from this page: http://wiki.koha-community.org/wiki/Category:Koha_3.4_RFCs to a page for 3.6 Nicole

1 0

Circulation Improvements
by Chris Cormack 06 Jun '11

06 Jun '11

Hi All Biblibre have done some good circulation improvements (bug 5872) but this is currently blocked by bug 5436 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5436 Work is being done on Hourly loans http://bugs.koha-community.org/bugzilla3/showdependencytree.cgi?id=5549&hid… And I want all of the changes in 5872 in with that. Would someone be able to look at 5436 and fix it up (the other 2 bugs 5872 depends on have made their way through sign off already). Thanks in advance Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand

1 0

Re: [Koha-devel] EAN-13 barcode support
by Chris Nighswonger 06 Jun '11

06 Jun '11

Hi Dobrica, On Mon, Jun 6, 2011 at 1:08 PM, Dobrica Pavlinusic <dpavlin(a)rot13.org> wrote: >> The scaling foo really follows no logic that I've be able to figure >> out yet. It is definitely not a "one size fits all" situation. Right >> now it is optimized for longer barcodes. Feel free to improve upon it >> if you are able. > > I was wondering what units are used for $bar_length, and I haven't > figured it out. IIRC all at that level are points. I'm pretty sure that I refactored the entire creator code to use points as its base unit. > > However, without scaling, barcodes are correct size (at least for > EAN-13/UPC-a which have "standard" size), so it's not a show-stoppper. I suspect this is true for the average user, which is why it has not been high on my list to work on (sorry everyone). If I can help by answering questions, please feel free to ask. My time right now is tight, so I can't do much more. Kind Regards, Chris

1 0

Z3950 search/UNIMARC
by Marcel de Rooy 06 Jun '11

06 Jun '11

Hi all, I am testing some changes in z3950_search.pl and I am wondering if the default Koha z3950 script correctly functions for unimarc targets (with marcflavor to unimarc as well of course). Could anyone of you using z3950 with unimarc reply on that? Is the MARC and Card view on the results screen correct too? Did you encounter problems with encodings? MARC-8, UTF-8, etc.? I tested with carmin.sudoc.abes.fr z3950 target? Could you recommend another one? Thanks for some feedback, Marcel

2 1

EAN-13 barcode support
by Dobrica Pavlinusic 06 Jun '11

06 Jun '11

I need to develop EAN-13 barcode support in next two weeks to migrate one university library from custom software. First step should be creation of RFC document, but I didn't receive confirmation e-mail from wiki, so I can't add it there directly. I tried with this and gmail.com e-mail address, so I would be greatful if somebody could help me with that. Basically, library now uses EAN-13[1] barcode which is zero-padded primary key in old system istead of ISBN or ISSN. Since books allready have barcodes on them, we can't change it. To make things more insteresting, at least one barcode reader reports it as UPC-A[2] without first leading zero, since EAN-13 has backwards compatibility with it. So, my first question is should I store barcodes padded with zeros in Koha? It seems that itemBarcodeInputFilter syspref and small change to barcodedecode in C4/Circulation.pm will support both solutions, and it seems to be that 13-digit EAN-13 with padded zeros is cleaner solution. Next, I would need to implement plugin which generates new barcodes in same format (with check digit). This would involve change to autoBarcode syspref in cataloguing/value_builder/barcode.pl and new C4/Barcode/EAN13.pm to support next barcode while ignoring last checksum digit. Finally, we need to print them. PDF::Reuse::Barcode allready supports EAN13, so it seems that small change to C4/Labels/Label.pm would be sufficiant. Am I missing something important other than tests? :-) 1: http://en.wikipedia.org/wiki/EAN-13 2: http://en.wikipedia.org/wiki/UPC-A -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

3 4

Re: [Koha-devel] Koha-devel Digest, Vol 67, Issue 7
by massoud alshareef 04 Jun '11

04 Jun '11

I second Chris's thought. There is only one community-driven OSS Koha! Thanks Massoud M. AlShareef, KnowledgeWare On Sat, Jun 4, 2011 at 1:00 PM, <koha-devel-request(a)lists.koha-community.org > wrote: > Send Koha-devel mailing list submissions to > koha-devel(a)lists.koha-community.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > or, via email, send a message with subject or body 'help' to > koha-devel-request(a)lists.koha-community.org > > You can reach the person managing the list at > koha-devel-owner(a)lists.koha-community.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Koha-devel digest..." > > > Today's Topics: > > 1. Re: KOHA version 3.0, my question is about the advantages of > KOHA 4 (Chris Cormack) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 4 Jun 2011 19:32:09 +1200 > From: Chris Cormack <chris(a)bigballofwax.co.nz> > Subject: Re: [Koha-devel] KOHA version 3.0, my question is about the > advantages of KOHA 4 > To: Clay Fouts <cfouts(a)liblime.com> > Cc: koha-devel(a)lists.koha-community.org > Message-ID: <BANLkTinqDbmXc3JhvkkvZnKRKxC4GqvRog(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > 2011/6/4 Clay Fouts <cfouts(a)liblime.com>: > > Github makes patch submission very easy. The typical process is to fork > the > > repository, commit your changes to your own fork (often on a topic > branch), > > then submit a pull request to the maintainer of the forked project. The > web > > interface provides simple buttons for forking (e.g. the LK-4.2 fork link > is > > https://github.com/liblime/LibLime-Koha/fork) and issuing pull requests. > The > > maintainer receives notification of the pull request and can then opt to > > merge the new commits back into the original repository. > > The service offers a nice interface to the whole code management process > and > > provides additional features for discussing patches, providing > line-by-line > > commentary, basic issue tracking, docs wiki, and so on. They offer public > > repositories for free, so there's a very low barrier to entry for open > > source developers. > > > > Internally we have released LK-4.4 and 4.6 into production and are now > > working on development branch 4.7. These are not publicly accessible, and > > that makes development of larger features pretty tricky if you're working > on > > the 4.2 release as your base. Anyone interested in creating a more > involved > > feature and ensuring it can be easily ported to future releases should > > consult us for pointers as there are notable architectural and schema > > differences. > > Right, perhaps we should move this off the Koha lists, Liblime run > their own lists for their project. This discussion about how to > contribute to the Liblime project is better there. > > Its fairly clear from Clays message, and comments on my blog etc that > what Liblime is developing is not Koha, and has diverged > significantly. So I say lets just keep discussion about Koha here, and > unless the discussion turns to how to reconcile the fork with the Koha > project, leave discussion of Liblime's Project for their own lists. > We don't discuss Koha on the Evergreen lists, and OPALS don't discuss > their project on the Koha lists. Liblime have their own project with > their own lists, lets leave them to it and get back to focusing on > Koha. > > Chris > > > ------------------------------ > > _______________________________________________ > 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/ > > End of Koha-devel Digest, Vol 67, Issue 7 > ***************************************** >

1 0

Koha 3.2.x String Freeze
by Chris Nighswonger 02 Jun '11

02 Jun '11

Hi all, The 3.2.x branch is in a string freeze for the 3.2.10 release as of the time of this email. I'm a few hours late, but needed to catch up on pushing some changes to the main repo. Keep in mind that 3.2.10 will most likely be the final release of the 3.2.x branch. Kind Regards, Chris

1 0