Time Nick Message 12:05 MrDys *yawn* 12:05 MrDys guten morgen 12:05 MrDys it looks like the first bugs I'm going to go after are the osx related ones...since that's my platform 12:05 kados are there OSX related ones? 12:06 kados maybe only by accident :-) 12:06 MrDys I was reading in the install that there's no z39 support and that 12:06 kados ahh 12:06 kados that should be fixed now 12:06 kados with the new Net::Z3950::ZOOM module 12:07 kados need to update the docs 12:07 MrDys ah fantastic 12:07 kados so you could test it out :-) 12:07 kados see if it works :-) 12:07 kados then update the docs :-) 12:08 MrDys hehe I will after my uke lesson 13:04 owen kados: still there? 13:04 dewey it has been said that there is a minor diff in <div>s, that I missed 13:04 kados owen: yep 13:04 kados I've updated the bug list 13:04 kados so it's readable 13:04 kados http://wiki.liblime.com/doku.php?id=koha226bugs 13:04 kados hehe 13:05 kados and linked each item to a bug in bugzilla 13:05 kados for reference 13:06 kados owen: so what's up? 13:07 kados damaged => don't show up in OPAC, can't reserve, can't issue 13:07 owen What did you have in mind when you brought up HLT's transfer/transit process? 13:07 kados well ... 13:07 kados don't they do something funky with branches? 13:07 kados you wrote up something about what NPL needed for transfers 13:07 owen yeah, they use branches like we would use statuses (like 'damaged') 13:09 kados hmmm 13:09 owen That's why they use Transfers extensively 13:10 kados I see 13:10 kados well ... 13:10 kados what if NPL used branches and branch categories 13:10 kados so you have two categories: 13:10 kados normal 13:10 kados transfers 13:10 kados branches in transfers are: 13:10 kados APL to NPL 13:10 kados NPL to APL 13:11 kados etc. 13:11 kados woudln't that work? 13:11 kados those would be in transit branches 13:11 kados or ... 13:11 kados a generic in transit branch 13:11 kados to make things really simple 13:13 owen To be honest, I think the only way folks are going to be happy is if Koha does /everything/ for them, just like Spydus does. 13:13 owen Meaning, if you check an Athens book in in Nelsonville, it's automatically made 'in transit from NPL to APL' 13:14 kados but 13:14 owen I don't think staff would be happy with a solution that required them to re-scan stuff 13:14 kados what about when you're in athen, and you check in a book on reserve in NPL? 13:14 owen Then it should automatically be made 'in transet from APL to NPL' 13:15 kados well IMO that's mainly interface 13:15 kados I think if we use 'in transit branches' we can acomplish what they want 13:15 kados we'd need to add a button to returns 13:15 kados when there's a reservation 13:16 kados they could click 'make in transit to NPL' 13:16 kados same thing when the holding branch isn't the same as the current branch 13:17 kados heh 13:17 kados why? 13:18 kados are there other cases to consider? 13:19 kados heh ... you could also search by in transit that way 13:20 owen Well, that's one problem with using Branches for something other than real branches: It messes up every interface where you get a branch choice. 13:21 owen So when the patron is trying to find their branch to reserve a book, they've got a bunch of 'junk' branches to sift through. 13:21 kados I thought there were certain hard-coded branch categories that didn't show up 13:21 kados if not, there should be 13:23 owen I said I was skeptical because I think any solution that involves extra scanning or extra clicking will not go over well with the staff. And from my point of view there's no reason /not/ to have the system behave as I describe. But that's because that's the way /I/ expect it to work best. 13:23 kados well ... we could make it happen behind the scene 13:23 kados s 13:23 kados wouldn't need to click anywhere 13:26 kados I'll ask chris when he's up what he thinks 13:28 kados hold the phone 13:29 kados why can't we just use the 'binding' status in items? 13:31 owen ? 13:31 kados for damaged items 14:04 kados owen-away: new bug in the Intranet found 14:04 kados owen-away: submitted as 1115 16:11 kados :( 16:12 tumer[A] kados: it just says not available 16:12 kados yea, that's just silly :-) 16:13 tumer[A] well some people still want to see the bibliographic record 16:13 kados yea 16:13 kados but some don't :-) 16:13 kados so we have a syspref 16:14 tumer[A] a use selectable pref better 16:14 kados s/have/should have/ 16:14 kados true 16:14 tumer[A] s/use/user 16:14 tumer[A] i mean in opac 16:34 kados yep 16:34 kados I agree 16:35 kados today 16:35 kados great 16:35 kados how's it going? 16:35 kados are you looking at rel_2_2 way? 16:36 tumer[A] yep 16:36 kados what are you having trouble with? 16:36 tumer[A] cloning a subfield messes the way authorities work 16:36 kados ahh 16:37 tumer[A] i have to understand this java 16:37 kados this is why we need one MARC framework :-) 16:37 kados and one MARC editor :-) 16:37 chris wont happen :) 16:37 tumer[A] the index numbers seem to change if you clone subfields 16:37 chris but one editor per framework could 16:38 tumer[A] i am talking about the MARC editor not authorities editor 16:38 tumer[A] in marc edtor we fill authors from authorities table 16:39 tumer[A] uneditable fields you see 16:39 chris yeah the marc editor as it current stands with its reliance on javascript is exceeeedingly fragile 16:39 tumer[A] its not set up for you so you dont probably see it 16:39 tumer[A] just like value builder but more complex 16:39 chris right 16:40 tumer[A] has to fill all subfields 16:40 tumer[A] why im i tumer[A] ?? 16:40 chris :-) 16:41 chris because of the way the form is built, adding subfields throws things off .. even with the value builder 16:41 tumer on the other hand cloning subfileds is very handy 16:42 chris yep 16:42 chris i wonder how far the opencataloger project got with the XUL based marc editor 16:43 tumer i never saw that just rumors about it 16:43 chris i must ask antoine 16:43 tumer has anybody thought of ISIS marc editor whether it can be implemented in koha 16:44 tumer its very advanced editor 16:44 tumer even with online help for each field/subfield 16:44 chris ill have to take a look 17:11 chris well since its the first day in the while i can see the sun (we've been having a lot of rain here lately) 17:12 chris i might go outside :) 17:31 kados tumer[A]: so a quick question if you're around 17:31 kados tumer[A]: am I correct that in dev_week, the only thing that is different is: 17:32 kados some routines in .pm files 17:32 kados searching with zoomsearch.pl (that I wrote) 17:32 kados ? 17:32 tumer[A] i thinkk yes 17:33 tumer[A] also circulation is a bit diff 17:34 tumer[A] dev_week when i uploaded my files may not have all the new stuff like branch specific aditing and issuing etc. 17:40 kados k 17:40 kados also ... 17:41 kados I've got a library that already has Koha 17:41 kados they are migrating to dev_week 17:41 kados I dump out the records in MARC21 17:41 kados then run them through a pre-process routine to fix them up 17:41 kados then I import them into zebra with zebraidx 17:41 kados but now I have a problem 17:42 tumer[A] but records will be in iso8759 17:42 kados because when I run biblio_framework.sql 17:42 kados the MARC will be different than what's in zebra 17:42 kados (ones in sql will be 8859 encoded, in zebra they will be utf-8) 17:42 kados (in sql, may be missing 090, in zebra they won't) 17:42 kados (etc.) 17:43 kados so I need a routine to add them back to Koha's sql 17:43 kados quickly 17:43 tumer[A] why run biblio_framework?? 17:43 tumer[A] keep their own framework 17:44 tumer[A] do not change their marc structure change zebra record.abs to matzch that 17:44 kados don't I need to move the MARC to the biblioitems table? 17:44 kados I have to change the MARC 17:44 kados for instance, the records don't have leaders 17:44 kados because the original version of Koha that 'supported MARC' deleted leaders! 17:44 tumer[A] yes you do and when you do marc will be in their structure 17:45 kados will MARCgetbiblio pull from Zebra? 17:45 tumer[A] no 17:46 kados grrr 17:46 tumer[A] when you are uilding and converting these marcs they will automatically have leaders 17:46 kados ok ... let me be clear 17:46 tumer[A] i now have ZEBRAgetbiblio 17:46 kados 1. I run updatedatabase from rel_2_2 17:46 kados 2. I export MARC records 17:47 kados 3. I run a script on the MARC that fixes several things (like adding proper leaders, but also other things, like 007 and 008) 17:47 kados 4. I import those fixed records into Zebra 17:47 kados now I have a problem 17:47 kados because the MARC in Koha is different than the MARC in zebra 17:48 kados so I need a ZEBRAgetbiblio I think 17:48 kados can you commit it to dev_week please? 17:48 kados I think that would solve my problem 17:48 tumer[A] why is it different apart from 007 and 008 which old koha does not use anyway 17:48 kados it is very different in many ways 17:49 kados and since dev_week still pulls from the koha tables for display 17:49 kados even for MARC display 17:49 tumer[A] by the way you reimport these marx into biblioitems so your matcs will be exactly the same 17:49 kados it is important that the two MARC need to be in sync 17:49 kados ?? 17:49 tumer[A] you missed one step 17:49 kados what step? 17:50 tumer[A] 5. import marcs into biblioitems 17:50 kados ok ... to do that I need a ZEBRAgetbiblio, right? 17:50 kados in move_marc_to_biblioitems.pl 17:51 tumer[A] no you build these marc somewhere wherverev you processed that 17:51 kados it calls MARCgetbiblio( $dbh, $bibid ); 17:51 kados and MARCgetbiblio, you said, does not use Zebra 17:51 kados so it will get obsolete data 17:51 tumer[A] ok 17:51 kados right? 17:51 tumer[A] maybe you have some scripts missing i'look 17:52 tumer[A] once you build these marcs in biblioitems export them out 17:52 tumer[A] process them outside utf8 007 etc 17:53 tumer[A] then i have import_ into_ biblioitems which just reads an external fiel 17:53 tumer[A] file i mean dont you have that 17:54 tumer[A] well i need a beer 17:54 kados :-) 17:54 kados me too :-) 17:54 tumer[A] i 2 check and commit it to dev week 17:54 kados thanks 17:55 tumer[A] that way the records that you will be indexing with zebra will be identical 17:58 kados great! 17:59 kados tumer[A]: does rebuild_non_marc work in dev_week? 17:59 kados guess it should as long as the API is unchanged 18:00 kados because if it does, it might be best to: 18:00 kados 1. export MARC 18:00 kados 2. pre-process to fix everything that's wrong 18:00 kados 3. import_into_biblioitems on a _brand new database_ 18:00 kados 4. run rebuild_non_marc 18:00 kados to populate koha tables 18:01 kados then ... import the rest of the data separately 18:01 kados issues, borowers, etc. 18:01 kados sweet 18:08 kados tumer[A]: having problems committing? 18:08 tumer[A] kados:rebuild_non_marc should work 18:08 tumer[A] i have committed 18:09 tumer[A] as long as its using MARCgetbiblio it should be ok 18:09 kados thanks 18:10 kados :-) 18:11 tumer[A] why are you thinking of importing into blank database? 18:11 kados well ... especially for NPL 18:12 kados historically, NPL was the first large library to go live with Koha 18:12 kados that was version 1.9 something 18:12 kados and the db has changed considerably since then 18:12 kados their db is a hybrid 18:12 kados updatedatabase doesn't fix it 18:12 kados so it would be easier to just import everything into a new db 18:12 kados separately 18:13 kados have a new MARC framework, etc. 18:13 tumer[A] very dangerous 18:13 kados why? 18:13 tumer[A] if itemnumbers change issues is a mess hapĂ°pened to me 18:14 tumer[A] issues and itemnumbers are all in sync. 18:15 tumer[A] if you are importing into a new database and not veeeery careful deb will produce new item numbers 18:15 kados right 18:15 kados shouldn't itemnumbers be the same? 18:15 kados with importtobiblioitems.pl? 18:16 tumer[A] when you use that biblionumbers are preserved. Itemnumbers are in the marc record. 18:17 tumer[A] But if you use Non_marc you have to make sure that its actually reading things correctly and not producing new numbers 18:19 tumer[A] on an empty database you cannot update itemnumbers to be the same 18:19 tumer[A] they have to be there to be updated 18:20 tumer[A] otherwise you will generate new numbers or lots of DBI errors 18:20 kados hmmm 18:21 tumer[A] on an update similar to that it took me a week to resync issues and items using there barcodes cause itemnumbers was changed 18:22 tumer[A] well i know you have backups so good luck 18:23 kados here is my plan: 18:23 kados assuming oldkoha.xml has old db listed and koha.xml has new one: 18:23 kados export KOHA_CONF = /koha/etc/oldkoha.xml 18:23 kados perl -I /koha/cvsrepos/dev_week/koha export.pl oldkoha.mrc # MARC records using special npl-specific export routine 18:23 kados export KOHA_CONF = /koha/etc/koha.xml 18:23 kados perl -I /koha/cvsrepos/dev_week/koha pre-process-mrc.pl oldkoha.mrc /koha/zebradb/records/newkoha.utf8.iso2709 # on new MARC records 18:23 kados perl -I /koha/cvsrepos/dev_week/koha import_into_biblioitems.pl /koha/zebradb/records/newkoha.utf8.iso2709 # to import the repaired records into biblioitems.marc 18:23 kados zebraidx -g iso2709 -c /koha/etc/zebra-biblios.cfg -d kohaplugin update /koha/zebradb/records 18:24 kados perl -I /koha/cvsrepos/dev_week/koha rebuildnonmarc.pl 18:25 kados the new koha db (was blank before) should have everything now 18:25 kados tumer[A]: right? 18:25 tumer[A] the last line worries me i'll check 18:27 tumer[A] 1.rebuildnonmarc will not work it calls marc_biblio and bibid which does not exist 18:29 kados damn 18:29 kados we need to fix it 18:29 tumer[A] 2.It calls for NEWmoditems which say update items where itemnumber=itemnumber 18:29 tumer[A] ie you have to have a populated database 18:30 kados grrr 18:31 kados and I assume bulkmarcimport won't either 18:31 Burgundavia hey kados 18:31 kados it will ignore itemnumber and biblionumber and create it's own I think 18:31 kados Burgundavia: hey there 18:32 Burgundavia who is responsible for the OPAC/Intranet web interface? 18:32 tumer[A] kados:if it does that than you re going to be in big trouble 18:32 kados Burgundavia: everyone :-) 18:32 Burgundavia ah 18:32 kados Burgundavia: you are in fact :-) 18:32 Burgundavia ouch, and I just joined 18:32 kados hehe 18:33 kados tumer[A]: can we get around it somehow? 18:33 Burgundavia I have been kicking around ideas about the OPAC interface since we talked at ALA 18:33 kados tumer[A]: it would really be ideal 18:33 kados Burgundavia: cool 18:34 kados tumer: maybe we can edit rebuildnonmarc to not require existing items if they don't exist but to create them 18:34 kados tumer: what do you think? 18:34 kados Burgundavia: remind me, who are you? :-) 18:34 tumer the only way is to use proprietary NEWmoditem 18:34 Burgundavia Corey Burger, Userful 18:34 kados right 18:35 kados tumer: by proprietary, you mean the one in dev-week? 18:35 tumer no we have to write one for this and not use Biblio.pm 18:36 kados tumer: my rebuildnonmarc uses 'localNEWmoditem' 18:36 kados tumer: not one in Biblio.pm 18:36 kados tumer: (in dev-week) 18:36 tumer aha 18:37 kados well ... still it uses Biblio in the end :-) 18:37 kados C4::Biblio::OLDmoditem( $dbh, $olditem ); 18:37 tumer still uses Biblio oldmoditem 18:37 kados so we need a localOLDmoditem and local NEWmoditem :-) 18:37 tumer which is the actual db sql script 18:38 kados hmmm ... why won't OLDmoditem work? 18:38 tumer thats where it says "update.. items" 18:38 kados my $query = "update items set barcode=?,itemnotes=?,itemcallnumber=?,notforloan=?,location=?,multivolumepart=?,multivolume=?,stack=?,wthdrawn=?,holdingbranch=?,homebranch=?,cutterextra=?, onloan=?"; 18:39 kados does't say 'where itemnumber=?' 18:39 tumer it should say "insert .. " 18:39 kados ahh ... itemnumber is autogenereated I bet 18:39 tumer no its not autogenerated 18:40 kados | itemnumber | int(11) | | PRI | 0 | | 18:40 tumer you cannot use update on a blank database 18:40 kados of course 18:41 tumer if you look the bottom of that script it says where itemnumber=? 18:41 kados tumer: I think we could use a single sql query 18:41 kados tumer: directly in the rebuildnonmarc.pl script 18:41 tumer yes can be so 18:42 kados Burgundavia: well you can see the two generations of OPACs in Koha: 18:42 kados http://opac.liblime.com 18:42 kados http://zoomopac.liblime.com 18:42 kados Burgundavia: the second being the one we're almost done with (but still quite a bit of interface cleaning to do) 18:44 kados tumer: does MARCfind_frameworkcode rely on koha tables or zebra? 18:44 tumer kados: if these people never mapped those fields to MARC they will all be blank 18:45 tumer frameworkcode only exists in SQL 18:46 kados uses bibio 18:46 kados that should be mapped to MARC 18:46 kados poor design 18:46 kados well ... it looks like my upgrade path for this lib is dashed 18:46 kados :( 18:47 kados well I can assume default framework actually 18:47 kados and make sure the framework is well defined 18:47 tumer do they have many frameworks? 18:47 kados no just one :-) 18:47 kados which is why this is simple :-) 18:47 tumer wouldn't default suffice 18:47 kados yep 18:47 kados perfect 18:47 kados so now I just need a custom rebuildnonmarc.pl script 18:48 kados that directly inserts into items 18:48 kados and uses default framework 18:48 tumer and all other atbles as well 18:48 tumer biblio, authors etc 18:49 kados yea 18:49 tumer infact you need a new importintobiblioitems.pl as well 18:49 kados hehe 18:49 kados my $sth = $dbh->prepare("select bibid from marc_biblio"); 18:49 kados that line kills my idea :-) 18:49 tumer you need a whole new set of scrippts 18:50 kados is there an equivilent in Zebra? 18:50 tumer not fiiling a blank db no. koha3 will have 18:51 kados well ... 18:51 kados bulkmarcimport.pl works 18:51 kados but it won't help because we've got issues data, etc. 18:51 kados shoot 18:51 kados I need a beer 18:52 tumer no it does not do what you want. Creates new biblionumbers and itemnumbers as far i remember 18:53 tumer it would ptobably be easier to write an upgrade script for the existing datavbase 18:53 tumer just add missing fields 18:53 kados hmmm 18:53 tumer convert the db to utf8 andd the 5 steaps you hav 18:53 kados but then we rely on the old db 18:53 kados for things like biblionumber :-) 18:54 tumer no 18:54 tumer your 5 steps ensures that biblionmbers exist 18:54 tumer also you can run rebuildnonmarc on taht 18:55 tumer and that ensures data is synced 18:56 tumer so before your 5 steps you just update the database to have missing fields thats all 18:56 tumer do not delete anything 18:58 kados tumer: when do I run convert_to_utf8.pl? 18:59 tumer after adding missing fields before exporting maRC 18:59 kados hmmm ... not sure about before exporting MARC 18:59 kados because I handle the transformation in my preprocess script 19:00 kados convert_to_utf8 doesn't update the leader 19:00 tumer k i dont know about convert_to_utf8 19:01 tumer i couldnt se it 19:01 tumer how does your preprocess convert from iso to utf8? 19:02 tumer if they are al ascii no problem though 19:03 kados it uses MARC::File::XML 19:03 kados some are not ascii 19:03 kados in fact, I expect many problems with charsets 19:04 kados so that's OK 19:04 tumer marcxml does not convert from iso8859 to utf8 19:04 kados true 19:04 tumer mysql will 19:04 kados I think these are actually in marc8 19:04 kados I'm not sure if mysqldump can even export them as marc8 19:04 kados i will do some tests 19:05 kados but I'm not that concerned about the encoding 19:05 kados most of this is ascii stuff 19:05 tumer it can 19:05 kados how? 19:05 tumer i have breeding in marc8 biblio in utf8 19:05 tumer well if they are already marc8 i mean otherwise no 19:06 kados they are in the db as marc8 19:06 kados but I think if I export them with mysqldump they are corrupted :-) 19:06 kados the nonascii ones at least 19:06 tumer in old koha only breeding is marc8 19:07 tumer it is not possible for them to be marc8 anywhere else 19:08 kados ahh 19:08 kados right 19:08 tumer because there is no marc objec t anywhere in old koha 19:08 kados right 19:08 tumer just lots of parsed text 19:09 tumer so encoding wise if its a problem est to convert to utf8 first 19:10 tumer but change your process to now that it should only change the leader when making marc 19:10 dewey tumer: that doesn't look right 19:10 tumer kados:we are having problems of definition i think 19:10 kados perhaps 19:11 tumer marchtml2marc can be tweeked to get utf8 data out with correct utf8 header 19:12 tumer thats the routine that builds your marc 19:12 kados !! 19:12 kados only in the old editor I hope 19:12 kados that routine is really bugy 19:13 tumer but whatever the data coming from it alwyas adds a marc8 header 19:13 kados well ... 19:13 kados in a new rel_2_2 install 19:13 kados if you import as utf8 19:14 kados it always comes out with a utf8 header 19:14 kados leader even 19:14 tumer i am talking about upgrading the old koha 19:14 kados ahh 19:14 tumer when you get marc out of it how is it build 19:14 kados using export.pl 19:15 kados so with a marc8 leader (but leaders have all been destroyed :-)) 19:17 tumer i do not have that old export.pl so i dont remember how marc is buit from marc_subfield_table 19:17 kados there is another complication with encoding to deal with 19:18 kados i have set up the server to default to utf8 19:18 kados but the old db is set to latin1 19:18 kados in mysql, 'show variables;' yields: 19:18 kados | character_set_database | latin1 | 19:19 kados | collation_database | latin1_swedish_ci | 19:19 kados and I don't think our convert_to_utf8.pl script will do the trick there 19:21 tumer you will need to tell tell that "character_set_client=latin1" character_set_results=utf8 and so ano and so 19:21 kados yea 19:22 tumer i have to get back to the authorities problem.Ping me if you nedd help 19:25 kados k, thx 20:35 Burgundavia kados: UI suggestions for the zoomopac interface. To you or to koha-devel? 20:43 kados Burgundavia: :-) 20:43 kados Burgundavia: there are many, I know :-) 20:43 kados Burgundavia: koha-devel is a good place 20:44 Burgundavia ok 20:44 Burgundavia I could start with the 4 tabs... 20:44 kados :-) 20:46 Burgundavia time to load up straining inbox even further 20:52 Burgundavia kados: is there a design document anywhere for the OPAC interface? 21:05 kados Burgundavia: nope 21:05 Burgundavia right, then you are getting one 21:05 kados sweet