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

RFC 3.2 : Item status bulk change
by Paul POULAIN 30 Jul '08

30 Jul '08

(http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:item_statuses_bulk_…) We will add a page to bulk change the status or location of an item. The page will let you : * choose the kind of info to change * the value to set Then, the librarian with scan barcodes and all scanned items will have the data updated. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08

7 10

Image-Magick replaced with GD
by Joshua Ferraro 30 Jul '08

30 Jul '08

Hi all, Just a quick heads up to developers that in line with the proposed solution to bug 2404, Image-Magick has been removed as a dependency and replaced by GD. Please bear this in mind if you're running off of a 3.0 Git repo as you may need to install these dependencies prior to upgrading to avoid any missing dependencies. Cheers, -- 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

Prepackaged perl distro
by Rick Welykochy 25 Jul '08

25 Jul '08

Hi Developers, I worked in an environment where a specific set of Perl packages known to work together well with everything else, i.e. database and web services, were required to create a virtual machine. We cobbled together perl + all perl modules required. The virtual builder then simply installed perl and all the perl modules we required. No CPAN. No failed makes. No mismatches. Can't the same be done for Koha? cheers rickw -- ________________________________________________________________ Rick Welykochy || Praxis Services || Internet Driving Instructor A lifetime of listening to disco music is a high price to pay for one's sexual preference. -- Quentin Crisp _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

6 17

Re: [Koha-devel] [Koha] ImageMagick
by MJ Ray 25 Jul '08

25 Jul '08

[thread moved to koha-devel] Marcel de Rooy <M.de.Rooy(a)rijksmuseum.nl> wrote: > While doing that, I had a problem installing a newer version of > ImageMagick (and PerlMagick). Koha needs 6.2. While installing one system recently, installing perlmagick pulled 109 other packages onto the system. Nearly all of the other koha dependencies were already installed, so didn't contribute to the 109. That's far too large a dependency tree for one perl module - 109 more bits we'd need to make sure work and have compatible versions. As Marcel de Rooy's message on the main koha list suggests, there may be also ongoing version-compatibility problems in ImageMagick itself. Is there any problem in principle in moving to something lighter, like a libgd-based solution? I suggest that this is a big enough bugfix to be introduced during 3.0 Comments? -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237

2 1

3.0 stable & improvements (for comments)
by Paul POULAIN 25 Jul '08

25 Jul '08

Hi folks, Look at commit : http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commit;h=64ba3ffe8309da1e10… The commit notes write : > Refine "Patrons statistics" report, fix highlight, remove CGI::scrolling_lists. > > At client request, I added code for a rowtitle_display and coltitle_display. This > allows the script to substitute human-readable lables into the table instead of just > the literal hashkeys. For this client with dozens of numerical patron categorycodes > having a row titled "29" was not very useful. I wanted to point the "at client request I added code..." 1st thought : it's an improvement, so it should not be here, as we are supposed to have only bugfixes 2nd thought : it's really minor, harmless & usefull, so it's good to have it anyway. So... once 3.0 is released, how will we deal with those cases ? Will our Release Maintainer (Joshua) decide which patches to cherry pick from head to have minor improvements ? Do we accept some improvements (I think we will have to do that : when a client request something, it's a problem to say "ok, it's minor, it's done, but it will be only available in 3.2, that will be released in X months" + if it's a sponsored feature, we (BibLibre or LibLime or anyone else probably won't be paid until the feature is available for the client) Another solution would be to have an official trunk & local versions for local clients. if I don't mind, LL don't want to do this, and BibLibre either. ideas / thought / welcomed... experience feedback : when I was RM for 2.x, I used to add minor features. What guided me : - is the improvement changing something in the DB ? if yes and very minor (like the add of a timestamp in virtualshelves table for example ;-) ), then continue investigating. If yes and not minor (adding contraints, foreign keys, indexes, "core fields", some tables...) , don't do it now. - if the improvement is changing nothing in the DB (or yes & very minor), does it change something in the API ? If yes => delay the improvement. I prefered to add some silly code to circumvent an API limit than change the API. That's the price for stability I think. If no API change => continue investigating. - will the improvement change the user experience (I don't mean improve something, but change the way Koha works). if Yes => delay the improvement. If no => continue investigating. - is the improvement correctly coded & do I feel it's OK ? Yes => OK, add it. To summarize, there can be 3 filters : DB change, API change, user experience change. Maybe not perfect + the # of devs was from far not as much as what we have now, but, at least, that was the way I tried to handle that problem. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

3 7

Status of serials/serials-recieve.pl
by Chris Nighswonger 25 Jul '08

25 Jul '08

Can anyone comment on whether serials/serials-recieve.pl is being used? If not, any objections to its removal? Kind Regards, -- Chris Nighswonger LibLime www.liblime.com chris.nighswonger(a)liblime.com

2 1

New 'test suite' component for bugs database
by Galen Charlton 24 Jul '08

24 Jul '08

Hi, I'd like to have a new 'Test Suite' component created on bugs.koha.org. This component would be for bugs and enhancements to the test suite itself (e.g., 2091) or for cleaning up problems identified by new tests (e.g., 2400); neither type of issue fits into 'command-line utilities', and I consider the test suite to be separate from installation. IMO, the default assignee should be Andrew Moore. since he's taken the lead on improving our unit tests. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709

3 2

Item status automatic change
by Paul POULAIN 24 Jul '08

24 Jul '08

(http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:item_statuses_auto_…) In Koha 3.0, the item status is set without duration. We will add a feature to explain how long a given status will be used, and which status must be set after that. That will be usefull, for example, to have a book with status “new book”, that is changed to “available” after 1 month. Or to have a book with status “lift”, changed to “reserve” after 1 day... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08

2 1

Re: [Koha-devel] MARC imports
by Michael Lasater 24 Jul '08

24 Jul '08

Hello, This is a record from the original MARC export: 01293pam 22003254a 4500001001300000003000600013005001700019008004100036010001700077020001800094020001500112035002700127040003200154050002300186082001300209100001900222245009600241260008200337300002600419651005200445650005200497650004600549600005100595650004600646651005400692650003700746650004500783651003700828999010200865BK0007443582OCoLC20080319000000.0071031s2008 cau 000 0deng a 2007043547 a9781593761691 a1593761694 a(Sirsi) i9781593761691 aDLCcDLCdYDXdBTCTAdYDXCP00aF595.3b.S735 200800a978.2221 aStegner, Page.10aAdios, amigos :btales of sustenance and purification in the American West /cPage Stegner. aBerkeley, CA :bCounterpoint :bDistributed by Publishers Group West,cc2008. axiv, 206 p. ;c24 cm. 0aWest (U.S.)xDescription and travelvAnecdotes. 0aWild and scenic riverszWest (U.S.)vAnecdotes. 0aWilderness areaszWest (U.S.)vAnecdotes.10aStegner, PagexTravelzWest (U.S.)vAnecdotes. 0aRafting (Sports)zWest (U.S.)vAnecdotes. 0aWest (U.S.)xEnvironmental conditionsvAnecdotes. 0aEcologyzWest (U.S.)vAnecdotes. 0aNatural historyzWest (U.S.)vAnecdotes. 0aWest (U.S.)xHistoryvAnecdotes. a978 STEwDEWEYc1i32003000651899lINPROCESSmSAVANNAHp$24.00rYsYtBOOKu6/10/2008x900zADULT Here is the same record after I have run my script on it: 01094nam 22002418 4500001001300000005001700013008004100030020001500071035002700086040001900113050002000132082001200152100004300164245007200207260005800279300004100337504005100378520015200429650001300581650002800594999012400622952010600746BK000414205320030925071029.0030925s2003 enkab b 001 0 eng d a0198606648 a(Sirsi) i9780198606642 aNjBwBTcNjBwBT14aQ126b.A85 200304a5002211 aAtkins, P. W.q(Peter William),d1940-10aGalileo's finger :bthe ten great ideas of science /cPeter Atkins. aOxford ;aNew York :bOxford University Press,c2003. aviii, 380 p. :bill., maps ;c25 cm. aIncludes bibliographical references and index. aA fresh take on the ten most important ideas in the history of science looks at such concepts as the expanding universe and the notion of the atom. 0aScience. 0aDiscoveries in science. a500 ATKwDEWEYc1i31989204164732d5/18/2004e5/11/2004lSTACKSmEASTSIDEn2p$30.00rYsYtBOOKu9/26/2003x500zADULT p319892041647324004bEASTSIDE10o500 ATKd9/26/2003850072cSTACKS2ddcg$30.00yBOOKaRHCLBB Thank you, Emmanuel Di Pretoro wrote: > Can you send a sample of your MARC file? > > 2008/7/23 Michael Lasater <mlasater(a)rollinghills.lib.mo.us > <mailto:mlasater@rollinghills.lib.mo.us>>: > > Sorry for the lack of information. I am using a version of Koha 3 > which is about a week old which I downloaded using Git. I am > using the import functions that are in the tools menu of Koha. I > have also used bulkmarcimport from the command line and had the > same results. > > Thank you. > > > Paul POULAIN wrote: >> Michael Lasater a écrit : >> >>> Thank you in advance for any assistance you may provide. >>> >> Hi Michael, >> >> 1st question : which version ? >> 2nd question : how do you import those biblios ? (bulkmarcimport ? >> through tools/ ? other method ?) >> >> > > -- > Michael Lasater > Rolling Hills Consolidated Library > 1912 N. Belt Highway > St. Joseph, MO 64506 > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel(a)lists.koha.org <mailto:Koha-devel@lists.koha.org> > http://lists.koha.org/mailman/listinfo/koha-devel > > -- Michael Lasater Rolling Hills Consolidated Library 1912 N. Belt Highway St. Joseph, MO 64506

1 0

RFC 3.2 : Patron reading record management
by Paul POULAIN 24 Jul '08

24 Jul '08

(copy of : http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_readingrecord…) Add a feature to let the patron manage it’s reading record himself. The laws in some countries requires that the library cleans the reading record after some time. This new feature will let the user himself decide what to do with the reading record. by default, the behaviour will be unchanged (clean borrower history after some time). An option will be added on OPAC to let the patron request “keep my reading record forever” (a checkbox). If the user uncheck it, the reading record will be cleaned later, by the cleanborrowers script. If the user uncheck it, the already deleted issues won’t reappear, of course. An option will be added on OPAC to let the patron request “clean my reding record immediatly”. That will clean (after a confirmation) the reading record for all issues that can be removed (ie : not current issues) The librarian won’t be able to set the “keep my record forever” himself, and it won’t be checked by default. The librarian will be able to see the flag. Technical notes : - add a field (keepreading) to members page & display it in members/moremembers.pl - modify opac-readingrec.pl to let the user change the status of this flag. - add a opac-emptyreadingrec.pl to remove the reading history. (ask for 2 confirmations before doing it, as it will be un-cancelable once it’s done) - modify tools/cleanborrowers.pl to deal with this flag -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel

4 5