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

Fwd: Generating transactions
by Chris Cormack 08 Apr '11

08 Apr '11

Forwarding to the list with Johns permission ---------- Forwarded message ---------- From: John Brice <jbrice(a)ccfls.org> Date: 9 April 2011 01:11 Subject: Re: [Koha-devel] Generating transactions To: Chris Cormack <chris(a)bigballofwax.co.nz> On 04/07/2011 04:56 PM, Chris Cormack wrote: > > On 8 April 2011 01:17, Anne-Lena Westrum > <anne-lena.westrum(a)kul.oslo.kommune.no> wrote: >> >> Dearest Koha developers! >> >> We have recently started a process of testing and evaluating Koha in the >> perspective of a fairly large public library, with a number of different >> branches and departments. This has proven to be a fairly timeconsuming >> task, as we - amongst other things - need to test all the modules and >> compare it to the functionality of our current ILS :) >> >> After importing our records (Normarc), we need to do a demo of the >> different modules. Thus we are in desperate need of a script to generate >> users (approx 500.000) and transactions (3-4 millions) over a period of >> time (4-5 years). >> >> We have had no luck searching for a script like this. Can someone help >> point us in the right direction? >> > Hi Anne-Lenna > > Magnus our NORMARC export (he wrote all the NORMARC support for Koha > and is from Norway also) is currently trying to sleep of a cold in > Marseille. He has been there for the week with Koha developers from > all around Europe working on a code sprint leading up to the release > of Koha 3.4.0 on April 22 (which will have native NORMARC support). > > I am sure he will answer when he wakes up :) As far as I know such a > script does not exist. I would offer to write one, as it sounds like > fun, but I am in the middle of release management work. I am sure > however that one of the other developers could do this. > > 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/ Hi Anne-Lenna: Years ago we tried to write such a script but it was much more complicated than we expected. For proof of concepts and demo purposes why not just load, from your current ILS, your transaction data into Koha? You will have to learn how to do this anyway so why not work out the transaction transfer now. John Brice Executive Director Meadville Public Library

1 0

String freeze is nigh
by Chris Cormack 08 Apr '11

08 Apr '11

Hi All The string freeze kicks into effect right about now. What does this mean, any new patches sent now, that touch templates and are not security related, will be deferred for 3.4.1. (New features of course are deferred to 3.6.x) On Monday NZ time, I will be merging the template::toolkit work into master and calling for lots of testing. I will create another branch that people can continue to use to sign off on old .tmpl files, and all ones submitted before Monday will be taken care of. Post Monday I will be asking that everyone makes patches based on the .tt files instead. I will post instructions in the mailing list, on the wiki and on the official Koha site, www.koha-community.org at that point also. Thanks all for your hard work, its looking like over 760 commits between 3.2.0 and 3.4.0 which is pretty amazing for 6 months work, and at last count nearly 70 people have patches in 3.4.0. The project continues to grow both in terms of community, and pace of development. So thank you all. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand

1 0

Lyon 2 University features
by Fridolyn SOMERS 08 Apr '11

08 Apr '11

Hie, This week, during th HackFest in Marseille, I started to create patches corresponding to features developed by Progilone for Lyon 2 university. First one is in bug 6120<http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6120>, based on features F10-F11 (see our git<http://git.progilone.com/?p=koha-lyon2.git;a=commitdiff;h=b51b944eb54fdb811…> ). We have discussed on the other features with Paul Poulain from Biblibre in order to give them priorities : More interesting : - F10-F11 (done) - F16 - F21-F22 - C1 Medium interesting : - F1-F13 Needs more developement : - F18 - F19 - C2 - C5 Not interesting : - F5-F6 - F7 - F14 - F17 - F27 - F28-F29 - C4 - C7 - C8 Obsolete : - F20 - C6 We will do your best to provide patches for the community version on interesting features. Best regards, PS : git clone works now on our git. (I'm starting to like git). PS : A* features are not new developments, they come from the Lyon 3 version managed by Biblibre. -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers(a)gmail.com

2 1

A new component in bugzilla
by Alex Arnaud 08 Apr '11

08 Apr '11

Hi all, It should be interesting to have a new component for bugs related to ILSDI in bugzilla ? proposals are: - External services Component - ILSDI - Web services - Other ? - or not ? Any thoughts ? Thanks Alex

5 10

patches "does not apply" in bugzilla
by Paul Poulain 08 Apr '11

08 Apr '11

Hello all, (and mainly chris_n, Darell Ulm, gmcharlt, hdl & Claire, Ian Walls, jwagner, Chris_c & Reed) i just finished reviewing patches in " does not apply" status in bugzilla. At time of writing, that's 44 patches. I've revived 8 patches that were "does not apply " but have a new version submitted. On the 44 does not apply patches, some are VERY old. This mail is a call to the original assignees If you don't submit a new version of the patch, I'll close the patch soon (in something like 2 weeks). If you still want to submit a new version but don't have time yet, please, add a comment to the bugzilla entry, i'll let it open. Here is a summary of assignees of patches older than (around) 6 months : ==== Chris Nighswonger ==== 5215 maj Barcode field not cleared when using "Add and Duplicate" option on additem.pl Catalogi 5250 enh Various enhancements to web based checkouts Self che 5263 enh Add support for including fields from the ISSUES table in advanced due notices Notices ==== Darell Ulm ==== 5292 enh Google Preview Option for OPAC OPAC 5299 enh Allow patron to update email if they are allowed to update password OPAC ==== BibLibre ==== 2809 nor Some search problems Searchin 3453 maj Opac authority search have a little problem Searchin 3553 nor do not allow to create code-less frameworks System A 3656 enh Specify fields to be omitted from the patron record Patrons 4032 enh XSLT systempreference should take a path to file rather than YesNo OPAC 3281 enh Item's summary parsing should be different Searchin ==== Ian Walls ==== 3393 maj Default branches and overdues notices Notices ==== Catalyst ==== 4460 nor Amazon's AssociateID tag not used in links so referred revenue lost OPAC 5172 enh Use other name rather than first name when referring to the user OPAC ==== Galen Charlton ==== 2488 nor OPACItemsResultsDisplay sys pref conflicts with singlebranchmode Searchin 2943 maj Search-results give incorrect 'availability' from missing 'maxItemsinSearchResults' syspref Searchin 3593 enh Term highlighting not working for exact term research and diacritics Searchin ==== JWAGNER for patches ==== 3478 enh Display patron middle initials Patrons 3483 enh Show number of OPAC renewals Circulat 3486 enh Checkout timeout button Circulat 3487 enh Don't allow payment of fines on items still checked out Patrons 3488 enh Suspend and reactivate holds Hold req 3490 enh Billing Notice/Debt Collect Patrons 3492 enh Set hold fees by item type and charge when hold placed Hold req 3496 enh Override maximum fine at checkout Circulat 3500 enh New Circulation, patron, fines, other granular permissions Authenti 3506 enh Block checkout of items with pending holds (allow supervisor override) Circulat 3507 enh Circ rules enhancements, maximum fine warning Circulat 3508 enh Limit number of on-shelf holds per day Hold req 3510 enh Allow staff to change checkin date and time Circulat 3658 enh Allow multiple criteria to be selected in Guided Reports and Statistics Reports Reports 3790 enh Fix item sort to be by library in OPAC record display, XSLT fix for call number spacing OPAC 3799 enh Allow OPAC to use separate advanced search type settings than staff OPAC 4237 enh Add other item statuses Catalogi 4238 enh OPAC timeout feature for patron privacy OPAC 4239 enh Allow holds on multiple items of selected titles Hold req 5193 enh Add specialized auction indexes and search options to Advanced Search Searchin -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0

How to resync biblioitem.marc, and (modified) biblioitem.marcxml
by pete huerter 08 Apr '11

08 Apr '11

Hi Koha-devel group, I just ran some SQL queries that changed the biblioitems.marcxml blob, but did not change the biblioitems.marc blob. What are the implications of this, and how can I fix this? It seems like I should be able to just do this to 'resync' these two fields: for each biblio, call biblio = GetBiblio call ModBiblio (biblio) Can someone please confirm? (or is there a better way to do this?) (Scroll down for more background info) Thanks, Pete. Background: During the bulk import process some of our biblios were imported with incorrect 952$8 Collection code (should be in CCODE authorised values list), and 952$c Shelving Location Code (should be in LOC authorised values list). E.g. "military o/s", should be "military o_s" which maps to "Military oversized" in the CCODE list. For this discussion let's assume that both 952$8, and 952$c need to be changed from "military o/s" to "military o_s". I thought I was being clever and used SQL directly to replace "miltary o/s" with "military o_s" in 4 places: 1. items.location 2. biblioitems.marcxml : field 952$c 3. items.ccode 4. biblioitems.marcxml : field 952$8 Sample SQL queries: # items.location UPDATE items SET items.location = REPLACE(items.location, 'o/s', 'o_s') WHERE items.location LIKE '%o/s%'; # marcxml blob 952$c UPDATE biblioitems SET marcxml = REPLACE(marcxml, 'rare/box', 'rare_box') WHERE extractvalue(biblioitems.marcxml,'//datafield[@tag="952"]/subfield[@code="c"]') = 'rare/box'; # items.ccode UPDATE items SET items.ccode = REPLACE(items.ccode, 'catalog', 'catalogue') WHERE items.ccode = 'catalog'; # marc blob: 952$8 UPDATE biblioitems SET marcxml = REPLACE(marcxml, 'catalog', 'catalogue') WHERE extractvalue(biblioitems.marcxml,'//datafield[@tag="952"]/subfield[@code="8"]') = 'catalog'; Then I realized that there is a second marc blob (biblioitems.marc) in addition to the marcxml blob (biblioitems.marcxml) - which looks like compiled marc? - that I did not change - yikes! When I look in lib/C4 it looks like GetBiblio (which calls GetBiblioMarc) uses the $marcxml to compose a Biblio $record. Biblio.pm@GetBiblioMarc: $record = eval { MARC::Record::new_from_xml( $marcxml, "utf8", C4::Context->preference('marcflavour') ) }; And it seems that ModBiblio (which calls ModBiblioMarc) compiles the $record into both formats, the marcxml blob, and the us_marc blob (compiled MARC?). Biblio.pm@ModBiblioMarc: $sth = $dbh->prepare("UPDATE biblioitems SET marc=?,marcxml=? WHERE biblionumber=?"); $sth->execute( $record->as_usmarc(), $record->as_xml_record($encoding), $biblionumber ); $sth->finish; There are also the following functions in Record.pm that look promising: Record.pm@{marc2marcxml,marcxml2marc, changeEncoding} It seems that generally biblioitems.marcxml is used more than the biblioitems.marc blob. It seems like I should be able to just, for each biblio, call GetBiblio followed by ModBiblio to 'resync' these two fields. Can someone please confirm?

1 0

(bugzilla)Does Not Apply => remember to change when updated
by Paul Poulain 08 Apr '11

08 Apr '11

Hello all, I'm reviewing all bugs with "does not apply" status. On the first 8, i've found 4 that have an updated patch, that applies. Sometimes there's a comment "pls try this" REMINDER : if you want ppl to signoff the new patch, PLEASE, set again "Please signoff". Otherwise, it will probably stay pending for some weeks, and once someone realize it can be tested again, it will probably not apply again... HTH -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0

Fwd: [OPEN-ILS-GENERAL] Notice of Change to License for OpenNCIP
by Galen Charlton 08 Apr '11

08 Apr '11

Hi, Please see this notice from the Georgia Public Library Service regarding relicensing OpenNCIP from the GPL v2 to the GPL v2+. As you can see, I am seeking confirmation from other copyright holders to approve the license change. As we all know, Koha currently embeds a fork of OpenNCIP. To assist with ending that situation so that Koha just uses OpenNCIP as a normal Perl dependency, I also call on any individuals and companies who have contributed patches to Koha's fork to express their willingness to have their code incorporated in a GPL2+ OpenNCIP. Regards, Galen ---------- Forwarded message ---------- From: Galen Charlton <gmc(a)esilibrary.com> Date: Tue, Apr 5, 2011 at 4:04 PM Subject: Re: [OPEN-ILS-GENERAL] Notice of Change to License for OpenNCIP To: Evergreen Discussion Group <open-ils-general(a)list.georgialibraries.org> Cc: Dan Scott <dan(a)coffeecode.net> Hi Elizabeth, On Apr 5, 2011, at 3:57 PM, McKinney, Elizabeth wrote: > Evergreen and other Open Source Community Members, > > The Georgia Public Library Service (GPLS) is the primary copyright holder on OpenNCIP. The source code can be found at the following sites: > > http://sourceforge.net/projects/openncip/ > https://github.com/atz/SIPServer > > As the director of the PINES program, I want to notify you that GPLS is permitting the change of the license of OpenNCIP from the GNU Public License version 2 to the GNU Public License version 2 or later in order to give it the same license that Evergreen uses. This will facilitate easier code sharing between OpenNCIP and Evergreen and thus benefit the Evergreen community. > > Feel free to distribute this notice as needed. Thank you for this. I confirm on behalf of Equinox that we are also willing to relicense any OpenNCIP code that we hold copyright on to the GPL version 2 or later. Based on the change logs, the following individuals may have individual copyright on portions of OpenNCIP. I now call on each of them to either approve the license change, object, or disclaim copyright interest. Joe Atzberger David Fiander Dan Scott If anybody is aware of other individuals with a copyright interest in the OpenNCIP code, please pass this request on to them. Regards, Galen -- Galen Charlton VP, Data Services Equinox Software, Inc. / Your Library's Guide to Open Source email: gmc(a)esilibrary.com direct: +1 352-215-7548 skype: gmcharlt web: http://www.esilibrary.com/ -- Galen Charlton gmcharlt(a)gmail.com

2 1

Koha - Bug 6113 enhancement to keep previous ids in bulkmarcimport.pl
by Linda Culberson 08 Apr '11

08 Apr '11

All, I have submitted Bug 6113 to bugzilla for a sponsored enhancement. In communicating with other Koha users, we feel that it would be highly beneficial Koha was enhanced to allow the library to keep its current ids when loading both bibliographic and authority records. Some of us have used our current control numbers in the 76X-78X fields to link records. In our institution, we have also used that number in external databases and on other websites to link additional information back to the related catalog record. The documentation within bulkmarcimport.pl also needs to be amended to better explain the use of the various options (for example: x, y, k, idmap and keepid) since some of us tried to use those to keep our ids without success. Thank you. -- 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 Facsimile: 601/576-6824

1 1

Technical question
by Charl 07 Apr '11

07 Apr '11

?Good day I need advice please. I have converted a Koha installation from 2 to Koha 3. Now there is a "syncronization" problem between the items table and the marc record in bibioitems. To make a long story short, the itemtype appears in the marc record, but not in the items table. Is there a procedure how to syncronize those 2 "fields"? Thanks for any advice!

3 5