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

bugzilla question
by Marcel de Rooy 04 Nov '10

04 Nov '10

Hi, Couldn't find this on the wiki. Should I leave a bug on resolved/fixed, resolved/invalid etc. or should they always go to closed in the end? Just some number: resolved+fixed=2636 bugs. Closed/fixed= only 78. Regards, Marcel

2 1

itemBarcodeInputFilter or Client side JS?
by Koustubha Kale 03 Nov '10

03 Nov '10

Hi All, We are implementing Koha at a college. They have a existing software for library. They have barcoded all their collection of about 150000 books with this software. The peculiar thing about the software and the barcode it generates is this : The barcode related data stored in the database of the software backend ( MS SQL) is the item's accession number & item type. The actual barcode is not stored anywhere. The printed barcodes are like this B011364, B011436, AR011346, AR011436,AR018100,AR018103,AR018104,AR018105. ( Note the duplicate accession numbers) The first alphabets correspond to the itemtype code stored in a table. The remaining numbers are the accession number stored in a table without the leading zeros. This causes a problem while migrating this data to Koha due to the missing leading zeros and arbitrary length of the string and the fact that accession numbers are same for different item types. While generating a barcode for a new item the software takes the itemtype and the accession number and prints out a barcode label in the required format. When the barcode is read back in the softwares circulation module by a barcode reader, a asp script on the server separates the item type and the accession number, strips the leading zeros from the numeric part and does a search on the database by means of a join on the two tables. As the college has stuck these barcode labels on all items, we have to figure out how to emulate this functionality in Koha. (Post migration we will generate & print barcodes from Koha; so we dont have to emulate this logic in the barcode generation for Koha). I was thinking we could store the barcode in Koha as itemtype-accession_number ( without the leading zeros e.g. AR-18100) retrieved from the old softwares database and when reading it in circulation in Koha we convert the barcode from for example AR018100 to AR-18100. I see two options to acchieve this.. options : 1) Create another filter for itemBarcodeInputFilter and modify the sub barcodedecode in C4/Circulation.pm 2) write a client side javascript to do it. I would like to know is 1) What is the better way to acchive this? 2) Is there way for us to avoid a patch to Koha which will probably be useless to anybody not migrating from this particular software. By using opacuserjs perhaps.. Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2

4 6

Classification Sources
by Cybermon 03 Nov '10

03 Nov '10

Dear Koha team, Can I use two classification sources for cataloging of Koha. For example, both of DDC and LCC. Sorry I could not find the BBK Classification of Russian in Koha. Please someone help about it. Gana

2 1

Getting rid of YUI ?
by Paul Poulain 02 Nov '10

02 Nov '10

Hi world, As you know, we are using both YUI and jquery javascript libraries in Koha. That's too much ! I think jquiry-ui (http://jqueryui.com) is good enough to decide to get rid of YUI. Pro: * jquery much more developed * yui & webdev have problems working together * a lot of informations are available for jquery, including tutorials and books * http://jqueryui.com/docs/Theming/API seems much more clear & easy to use to me than yui css (is it just me ?) * jqueryui comes with (a themable) complete set of icons Cons: ? (Anyone want to argue ?) So, I propose the following roadmap : * new templates should be developed using jquery, not yui * 3.4 would still have both * in 3.6, we get rid of yui Other question : should we have jquery code inside koha (and thus having to take care of the updates) or should we use an external source ? (does this exist ? for yui it does, see yuipath syspref in koha) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

8 8

Re: [Koha-devel] wiki [important] changes & request for reviewing
by MJ Ray 02 Nov '10

02 Nov '10

Paul Poulain wrote: > - http://wiki.koha-community.org/wiki/Category:Abandoned_RFC => contains > abandoned rfcs (because it's no more relevant or we have lost contact > with the developer) I've rescued two of them (multi-level biblios and requiring items) which I'd still like to see in 3.4 although I have no funding for them at the moment. > on page : http://wiki.koha-community.org/wiki/Category:RFCs there are > still 19 pages that I don't know what to do with. > > FOLLOW-UP => ANYONE who has entered a RFCs on the wiki should go and > double-check that it's at the right place. On some RFCs, the author was > displayed in the RFC itself (BibLibre or Liblime most of the time, but a > few others), but the edition history has been lost when we moved the > wiki. So, for many RFCs, there is no information in the RFC itself and > it seems to have been filed by nengard, which is wrong. Why didn't you ask? I have a copy of what I think is the edit history, although the move also disrupted it by renaming many pages. Here is a list of RFC creator usernames from the old wiki: rfcs3.2:rfc32_hourly_circ gmc created rfcs3.2:rfc32_email_checkout_slips gmc created rfcs3.2:rfc32_fine_thresholds gmc created rfcs3.2:rfc32_opening_hours gmc created rfcs3.2:rfc32_recalls gmc created rfcs3.2:rfc32_holdability_flag gmc created rfcs3.2:rfc32_notifications_and_opac_messaging gmc created rfcs3.2:rfc32_system_groups gmc created rfcs3.2:rfc32_marcstructure_translation eric.begin created rfcs3.2:rfc32_description_translation eric.begin created rfcs3.2:rfc32_readingrecordhistory tipaul created reading record management by patron rfcs3.2:acq-permissions nicomo created rfcs3.2:create-item-when-ordering nicomo created rfcs3.2:enhance-closing-basket nicomo created rfcs3.2:refining-budgets nicomo created rfcs3.2:better-stats-about-acq nicomo created rfcs3.2:refining-budgets-management nicomo created rfcs3.2:bib-search-acq nicomo created rfcs3.2:searches-on-orders nicomo created rfcs3.2:suggestion-opac-searchtest nicomo created rfcs3.2:suggestion-opac-hold nicomo created rfcs3.2:suggestion-staff-workflow nicomo created rfcs3.2:pqf_search tipaul created rfcs3.2:display_item tipaul created : RFC for displaying items in large networks rfcs3.2:rfc32_koha_api_uml_diagrams_and_e-r_diagrams tajoli created rfcs3.2:rfc32_guided_reports tipaul created guided reports improved rfcs3.2:rfc32_turn_on_warnings gmc created rfcs3.2:rfc32_general_holds_improvement gmc created rfcs3.2:rfc32_hold_request_targeting gmc created rfcs3.2:rfc32_ajax_in_the_staff_interface pianohacker created rfcs3.2:rfc32_advancedpatronsearch danny.bouman created RFC for advanced patron search rfcs3.2:buying-analysis tipaul created rfcs3.2:rfc32_cas_compatibility nicomo created rfcs3.2:rfc32_unsaved_changes_notification danny.bouman created rfcs3.2:advanced_cataloging_search danny.bouman created rfcs3.2:rfc32_fast_add danny.bouman created rfcs3.2:rfc32_syndetics_support danny.bouman created rfcs3.2:rfc32_place_hold_multiple_items danny.bouman created rfcs3.2:rfc32_tag_multiple_items danny.bouman created rfcs3.2:rfc32_holdings_structure gmc created rfcs3.2:authority_control_improvements gmc created rfcs3.2:rfc32_brief_records gmc created rfcs3.2:improved_batch_capabilities danny.bouman created rfcs3.2:rfc32_improved_permissions danny.bouman created rfcs3.2:rfc32_staff_place_hold_opac danny.bouman created rfcs3.2:rfc32_import_export_system_preferences danny.bouman created rfcs3.2:rfc32_barcode_prefixes rch created rfcs3.2:rfc32_multiple_opac rch created rfcs3.2:rfc32_take_items_out_of_bib gmc created rfcs3.2:storequeries hdl created rfcs3.2:rfc32_improved_security pustake created rfcs3.2:rfc32_item_level_itemtypes rch created rfcs3.2:blocking_non_blocking_rules tipaul created rfcs3.2:fines_in_days tipaul created rfcs3.2:dbix-class amoore created rfcs3.2:rfc32_biblio_table rch created rfcs3.2:rfc32_subtitle_field mdhafen created rfcs3.2:requiring_items mjr created rfcs3.2:rfc32_circ_policies rch created rfcs3.2:rfc32_patronselfprivacy tipaul created : RFC for patron dealing with their Reading History at OPAC If any appear multiple times, I think the later ones are translations. Perhaps someone could recover any RFCs that they think are/should not be abandoned, based on that list? Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work http://www.software.coop/products/

2 1

Template for RFCs updated
by Paul Poulain 02 Nov '10

02 Nov '10

Hello, it's a follow-up of my yesterday mail about the wiki RFC template: i've updated the template for RFC. Now, you can/must also enter the bugzilla number, like this : |bug=<bugzillanumber> The number will be transformed into a nice url to the bug itself, just enter the number (|bug=5420) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0

RFCs for 3.4 from BibLibre (serials & acquisitions)
by Paul Poulain 02 Nov '10

02 Nov '10

Hello, I have filed RFCs for all enhancements you can expect from BibLibre in the next few months. All of them are sponsored (by Saint-Etienne University), and will have to be delivered to the library for a "go live" in May-2011 * You can find them on the wiki (search biblibre rfc for3.4) : http://wiki.koha-community.org/w/index.php?title=Special:Search&ns0=1&redir… <http://wiki.koha-community.org/w/index.php?title=Special:Search&ns0=1&redir…> * You can also find them on bugzilla : i've added a saved search, shared with everybody, called "Koha 3.4 enhancements". They are only related to serials and acquisitions. What's the next step ? * read the RFCs * comment them (on the wiki or on bugzilla) * we will probably propose/organise an IRC meeting to discuss & get any feedback for all those incoming developments. None of them (except the solR one) has started, so if you want to give us an advice, add something, ... it's now or it may be too late ;-) <http://wiki.koha-community.org/w/index.php?title=Special:Search&ns0=1&redir…> -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0

Changing default koha mapping 440$a -> 490$a
by Robin Sheat 01 Nov '10

01 Nov '10

In 2008, the 440 MARC field was obsoleted[0], and 490$a is the equivalent. Default Koha installs (unless it was updated relatively recently) map 'seriestitle' to 440$a. I'm planning to update this to 490$a for a client's install, but was wondering: a) is this likely to make things blow up in unexpected ways?, and b) is this worth putting into the default Koha mapping so that new installs have it set up correctly? For obvious reasons of not messing with peoples' data, adding this as a database update is probably a bad idea, but is there any issue with having it as the new default? [0] http://www.loc.gov/marc/bibliographic/bd4xx.html -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D

2 1

Koha 3.2 : bulkmarcimport.pl/bulkauthimport.pl
by Linda Culberson 01 Nov '10

01 Nov '10

Everyone, I apologize if this is the wrong list for this question. There is considerable change in the bulkmarcimport.pl script and it seems to be written to handle authorities as well as bibliographic records. I loaded my authority records using bulkauthimport.pl as I did in 3.1, and it worked fine, but I was wondering if I should be using bulkmarcimport.pl for both authorities and biblios (in other words, is bulkauthimport.pl being deprecated?) I also still have the need to be able to retain our system identification numbers from the 001 as the biblio.biblionumber because it is used to tie our analytics to the host record and it is used in links to non-MARC databases. I see that there is still /usr/share/koha/bin/batchImportMARCWithBiblionumbers.pl and 3.2's bulkmarcimport.pl does seem to allow for a "-k" "keepids" option (although the script does state that is is .."for authorities, where 001 contains the authid for Koha, that can contain a very valuable info for authorities coming from LOC or BNF. useless for biblios probably") I tried unsuccessfully to use that option for biblios, and wondered if anyone else was working on a similar problem. Thanks in advance. -- 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 0

wiki [important] changes & request for reviewing
by Paul Poulain 01 Nov '10

01 Nov '10

Hello, Those who have an RSS feed on the wiki may have seen a lot of changes. It was a task I planned to do during hackfest. Couldn't but today I could ! I've cleaned A LOT all RFCs, I hope (and think) it's much more clear now ! I've created 3 new categories : rfc_for3.2, rfc_for_3.4, abandoned_rfc I've checked *all* (109 !) rfcs and added/modified the categories to be the right one. So, now: - http://wiki.koha-community.org/wiki/Category:RFCs:for_3.2 => contains rfcs for 3.2 - http://wiki.koha-community.org/wiki/Category:RFCs_for3.4 => contains rfcs that have been announced as expected for 3.4 - http://wiki.koha-community.org/wiki/Category:Abandoned_RFC => contains abandoned rfcs (because it's no more relevant or we have lost contact with the developer) on page : http://wiki.koha-community.org/wiki/Category:RFCs there are still 19 pages that I don't know what to do with. FOLLOW-UP => ANYONE who has entered a RFCs on the wiki should go and double-check that it's at the right place. On some RFCs, the author was displayed in the RFC itself (BibLibre or Liblime most of the time, but a few others), but the edition history has been lost when we moved the wiki. So, for many RFCs, there is no information in the RFC itself and it seems to have been filed by nengard, which is wrong. I also have modified the tags "Version". I propose that the tag "version X.Y" to be checked only when the feature has been integrated in master branch (it's sure it will be a part of the release X.Y) Thus, i've removed all "3.4" tags, they will be re-checked later (and RFCs_for3.4 is clear) Other points = * the page http://wiki.koha-community.org/wiki/Category:RFCs describe the workflow * pls note I've created a template for RFC (i haven't adapted existing RFCs). If something is missing in this template, let me know (or update it, it's quite easy !). We (BibLibre) will use this template for the coming-soon RFCs ! Will now work on BibLibre RFCs for 3.4. (That may be 40, mostly for acq & serials ) HTH -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0