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