| Time |
S |
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 |
