Time  Nick       Message
12:27 nengard    hey all - sys pref question - shouldn't OPACUserCSS default to '' ?  Right now it's defaulting to '0' ... isn't that printing out a 0 somewhere in the code??
12:39 nengard    hey all - sys pref question - shouldn't OPACUserCSS default to '' ?  Right now it's defaulting to '0' ... isn't
12:39 owen       If so, nengard, then you're right--that's a bug.
12:41 nengard    owen - oops - here's my full question
12:41 nengard    hey all - sys pref question - shouldn't OPACUserCSS default to '' ?  Right now it's defaulting to '0' ... isn't that printing out a 0 somewhere in the code??
12:41 nengard    i am just a bug magnet
12:41 owen       I think no, because the template system will interpret "0" the same as "empty."
12:42 owen       So it's a minor bug
12:42 nengard    ah - but it should still be an empty string?
12:42 nengard    ok
12:51 thd        kados ping
12:54 owen       kados is on the road, thd, so I don't know if you'll be able to catch him
12:55 thd        owen: which road is that?
12:55 owen       All of them, I think. He had a huge itinerary
12:58 thd        owen: will bug #218 be on your itinerary in future?
12:58 owen       218?
12:59 owen       thd, do you mean 2189?
13:00 thd        owen: #2169 I mean. It was not one that I was thinking of my latest koha-devel list posting but kados had asked me to post that bug almost a year ago.
13:01 owen       I would like to see Bug 2169 fixed just as much as you, but it's outside of my expertise.
13:01 owen       Bug 2169 has *always* existed, as far as I know.
13:01 thd        s/#2\d+/#2189/ # tubule tying today
13:02 owen       ?
13:02 thd        another always existed
13:02 thd        2189
13:03 owen       thd, is the primary issue of 2189 that of database field sizes?
13:04 thd        owen: yes it is not a bug in itself but has been an obstacle to fixing bugs by raising the number of changes required
13:06 thd        owen: although one current bug is directly caused by it perhaps
13:07 owen       "The only Koha code which restricts the size of organisation codes to my
13:07 owen       knowledge is the hard coding in the templates."
13:07 owen       The templates are generally set up to match field sizes in the databases
13:07 owen       The database is not configured to match form field sizes
13:10 thd        owen: I did not look to see where the problem was I only guessed
13:11 owen       If there is a problem with the size of database fields they can certainly be changed, but it's necessary to pick a limit
13:12 thd        owen: what then restricts the ability to enter more than a given set of characters in a Koha for field?
13:12 owen       It's true that the templates may need to be changed to reflect the database field limits, but it's the database that sets the limit, not the templates
13:13 owen       The templates just have a maxlength attribute applied to the input tag
13:14 thd        owen: exactly it is the maxlength value which causes the problem
13:14 thd        owen: the maxlength value is hardcoded when it need not be
13:15 owen       The maxlength attribute should reflect the maximum number of characters allowed by the database field
13:15 owen       Unless you're finding that the database field allows enough characters but the form field maxlength is smaller
13:17 thd        owen: are you saying that maxlenghth is currently read from the database limit for that field in real time?
13:17 owen       No
13:18 thd        owen: then it is hard coded as I had presumed?
13:18 owen       Yes
13:19 thd        owen: my suggestion is to calculate it in real time from the database maximum for the particular field
13:19 hdl        thd: hi
13:19 hdl        nice to see you
13:19 atz        thd: that does not sound very reasonable
13:19 owen       Why? Because you suspect libraries will be changing the size of their database fields?
13:20 thd        hello hdl
13:20 hdl        this would really be MUCH proc-intensive.
13:20 thd        owen: because it is self validating and allows changes when necessary
13:20 atz        the cataloging module in particular would drag incredibly
13:21 atz        it is perfectly valid for a DB field to have capacity greater than the interface makes use of
13:22 thd        hdl: well if excessive CPU would be required then we need your idea of auto-building templates from a configuration file
13:23 thd        not that that would happen any time soon
13:23 thd        non-real-time auto-building
13:24 thd        build them whenever the database changes
13:24 atz        what fields, specifically, do we think any library would be interested to enlarge?
13:26 thd        atz: I mention 2 in bug #2189 as mere examples.  Any where enlarging would suit a local need.
13:26 thd        owen: #2095 may be a currently problematic instance.
13:28 thd        owen: for #2095 maxlength should be no smaller than the maximum size of a MARC record and should not need to be even that small for MARCXML.
13:29 owen       thd, your comments are much better addressed to atz and hdl, since you're not talking about a template issue
13:29 thd        owen: is 2095 not a template issue?
13:29 atz        thd: as a practical matter, I think it would be far easier to address specific problems than to convert wholesale to adding an extra variable for every input field
13:29 owen       thd: no, not as far as I know
13:30 thd        owen: OK
13:30 atz        thd: as I said earlier, it is perfectly valid for the interface to specify a lower limit than the DB field's capacity
13:30 nengard    just want to confirm that this sys pref 'RoutingSerials' is talking about serials routing lists?
13:31 hdl        nengard: yes
13:31 nengard    thanks hdl
13:31 thd        atz: the intention was to make Koha easier to customise but why should the interface limit valid data?
13:32 atz        because the *limit* could be valid.
13:32 atz        not to mention it keeps your server from getting overrun
13:33 atz        how is this problem critical?
13:33 thd        atz: the first example I describe in bug #2189 is a case where any smaller limit would not allow standards conforming data.
13:33 atz        the examples cited are either problems that are already fixed, or ones that *might* occur later
13:35 thd        atz: yes, as I told owen a few minutes ago it is not a bug in itself but has been an obstacle to fixing bugs by raising the number of changes required
13:35 atz        of course revising the structure that broadly would require an enormous number of changes
13:38 atz        for specific fields that we consider more volatile, we might be able to take this approach relatively soon
13:38 thd        atz: yes, I presumed that it was easier to make that change once but if the method is too CPU intensive or would require rewriting how the templates used are built for a batch process then I will withdraw the bug to an enhancement for the distant future
13:38 thd        atz: which approach?
13:39 atz        the dynamic approach
13:39 thd        atz: I see for a small number deemed liable to change
13:39 atz        i'm saying we might be able to use this selectively, rather than with every input field
13:39 atz        right
13:42 thd        atz: I guess my thinking was only concerned with values which should not be so small that they could not be used for giving a semantically meaningful name in coded form.
13:45 thd        atz: I think that if the few cases of which I am thinking were hard coded at a maximum of 32 characters in the database and the templates you would never see any problem for decades.
13:47 atz        thd: that sounds more feasible
13:47 thd        atz hdl: if the templates are not the cause of bug #2095 then what would be?
13:47 atz        thd: or in the case of framework code and even organization code, perhaps all that is needed is an additional "description" field to allow the longer te
13:47 atz        *text
13:49 atz        thd: i don't know about #2095.  that seems odd.  can you give a URL?
13:50 atz        or nengard, perhaps you can elaborate?
13:50 nengard    atz - off to read it
13:51 atz        134 is a weird number indeed
13:51 hdl        thd : Some notes fields in UNIMARC are Textarea notes and not input fields.
13:51 nengard    what's the question?  when I entered in the 520 field it stopped me from typing after 134 characters - i was in the cataloging module when doing this
13:51 hdl        Would that be enough for you ?
13:52 thd        atz: there is one description field already for the frameworks but it shows what the librarian wants to see and not what they hope not to no about what the framework.  A framework memonic is so the person editing the frameworks can be reminded what he is really editing.
13:52 atz        nengard: can you give a URL so I know what page to look at?
13:52 nengard    atz koha/cataloguing/addbiblio.pl?frameworkcode=BKS
13:53 thd        nengard: I did not see this bug myself.  Which Koha editor does it affect?
13:53 nengard    thd - maybe it cut it off after i submitted it - or maybe it has been fixed
13:53 nengard    it has been a while - let me go try to edit a record ....
13:54 thd        nengard: no I mean that I did not test it
13:54 nengard    oh
13:55 thd        nengard: I see by the URL that you mean the guided forms based record editor not the newer biblios record editor.
13:56 hdl        atz : it is quite puzzling for me that C4::Context could use C4::Context->preference in its BEGIN block.
13:56 hdl        Is it allowed ?*
13:56 owen       There are several instances of 'maxlength="255"' in addbiblio.pl, which I assume correspond to database field limits
13:56 nengard    thd hdl atz - i just tested in the newest version i have and it is not limited
13:57 nengard    i got over 400 characters into the field when editing
13:57 atz        hdl: it is an unusual exceptional case
13:57 nengard    here's the edit URL: koha/cataloguing/addbiblio.pl?biblionumber=263&op=
13:57 atz        see what is happening is that the sub "handle_errors" is being defined
13:57 thd        owen atz: most subfields have no limits defined in the MARC standards and should not be limited in any significant way.
13:57 nengard    thd++
13:58 atz        that *sub* uses ->preference, but the sub itself will not be called until after the BEGIN block.
13:59 thd        owen: what record editor fields are limited to 255 for records?  That is too big for any fixed length fields and too small for anything else by the standard at least.
13:59 atz        hdl: does that make sense re: Context?
13:59 hdl        atz : asking it because on SUN it threw me out.
14:00 atz        hdl: interesting
14:00 atz        what version of perl?
14:00 hdl        5.8.5
14:00 mc         hello all
14:01 thd        hello mc
14:01 hdl        thd : mc is a BibLibre man.
14:01 owen       thd: view source on the Add MARC page to see
14:02 hdl        mc: thd is american and worked on MARC21 frameworks. he is really helpful in general use cases.
14:02 mc         thx, hdl
14:03 thd        mc: do you live in France?
14:03 mc         thd, yep
14:03 mc         strasbourg
14:03 mc         near germany
14:03 mc         (right at the frontier, in fact)
14:04 mc         hdl: peraps it's time for me to read the perldoc again but BEGIN block is executed asap
14:04 mc         when bytecodinf
14:04 mc         bytecoding
14:05 mc         so you can't use C4::Context in the C4::Context's BEGIN
14:05 hdl        atz ?
14:06 atz        sorry, on conf. call..... bbl
14:07 mc         hdl: i just verified with a simple code
14:07 mc         and it is!
14:08 hdl        Can you detail ?
14:08 hdl        it is what ?
14:12 mc         hdl, are you talking about this line :
14:12 mc          30                                 my $debug_level =  C4::Context->preference("DebugLevel");
14:14 hdl        yes
14:17 thd        nengard: how did you fit 400 characters into a field defined as maxlength 255?
14:17 nengard    LOL
14:17 nengard    no idea :)
14:17 nengard    but it worked
14:17 nengard    .....
14:18 nengard    504 -BIBLIOGRAPHY, ETC. NOTE
14:18 nengard      a Bibliography, etc Includes bibliographical references and indexes.
14:18 nengard    520 -SUMMARY, ETC.
14:18 nengard      a Summary, etc Learning to Teach in an Age of Accountability, by Arthur Costigan and Margaret Smith Crocco, with Karen Kepler Zumwalt, documents the voices of many new teachers -- important voices, articulate voices, emotional voices. In an age of accountability, these voices bring to light many significant struggles, tensions, and conundrums that exist for them as they enter middle and secondary school environments. ?Teaching Educ
14:18 nengard    ation
14:18 nengard    this  - after i hit submit
14:19 owen       If it's a textarea, then there isn't a maxlength
14:19 owen       maxlength only applies to input type="text"
14:19 paul       nengard: in MARC editor, there is an automatic mechanism that transform a input into a textarea when subfield size is >200
14:19 thd        owen: I see maxlength 255 everywhere
14:19 paul       + all notes fields are automatically set to textarea
14:20 thd        paul: I see 255 for some notes fields at least
14:20 nengard    paul - i did notice that when adding a new record the field was a text field and when editing it was textarea ...
14:21 nengard    is there anyway to make it always a textarea?
14:31 paul       nengard: what do you mean by "it" ?
14:32 nengard    sorry - 520 $a on addbiblio.pl
14:32 nengard    oh - i was editing a biblio
14:32 nengard    paul - let me start over
14:32 owen       You could even auto-resize your textareas: http://zivotdesign.com/examples/jquery/textarea.html
14:33 nengard    when viewing the 520a field when adding a new record on addbiblio it was a text field when editing a biblio it was a textarea
14:35 hdl        owen : COOOL ;)
14:36 owen       jquery++ :)
14:36 thd        owen: those 255 limits to the extent I have seen them would not be enough on some rare occasions like lengthy statements of responsibility or the longest narrative titles given to some 18th century books.
14:37 paul       one day, /me will find some time to investigate jquery a lot...
14:38 thd        owen: since the cataloguer should know enough not to abuse the system 255 should be something like text but not text area.
14:39 thd        s/know/be trusted/
14:42 thd        owen: no arbitrary limit like 255 should ever allow any possible real world record to have truncated subfields even if no one writes long 18th century book titles when writing books today.
14:47 nengard    thd - i've seen those long titles today :) hehe
14:48 thd        owen: adding a 0 to 255 would be enough but in case some note subfield was accidentally missed 99999 is the maximum size of a MARC record and certainly safe where 255 would not be.  We should never have a risk of data loss merely by saving a record into the editor.
14:51 thd        nengard: I am waiting for the eighteenth century enlightenment to come back into full fashion so we can get out of the neo dark ages.
14:52 nengard    heh
14:57 owen       I'm waiting for all new nonfiction titles to stop following the same pattern: "BIG WORD!: how blah blah blah and more blah blah and even more and more buy my book"
14:58 gmcharlt   owen: it's a requirement of PhD to sign a blood oath to entitle all monographs that way
14:59 hdl        lol
15:03 nengard    ehe
15:04 thd        The rule for determining which subfields should be notes subfields and therefore textarea is much too simple.  A frameworks value would be required to do it correctly.  Only the most important ones have been caught.
15:05 thd        owen: I propose that 255 be changed to 99999 to avoid a data loss risk.
15:05 thd        ... for addbiblio.pl .
15:07 owen       Since no one would want to edit 99999 characters from a single-line text input field, the correct solution would be to convert all to textareas
15:08 thd        owen: 99999 is merely the theoretical maximum for the standard :)
15:09 owen       But my point stands: I wouldn't even want to have to edit 255 characters from a single line input field
15:10 thd        owen: I guess you are right that if you were cataloguing those very long book titles you would want it to become textarea so you could see what you would be doing.
15:11 owen       Which is why it might be good to convert all inputs to single-row textareas and make them automatically resizeable
15:11 thd        owen: as long as those are only textarea when the transition point has been passed then making everything textarea should be fine.
15:13 atz        lol gmcharlt : you know, sometimes I want to escape from the koha list, too.
15:13 gmcharlt   atz: heh - at least we're paid, in effect, to be on it
15:13 gmcharlt   ;)
15:14 thd        being unpaid: I sadly no longer read the koha list
15:15 owen       Generally the koha list can be considered the koha-install list
15:16 paul       hi gmcharlt. Pls note my comment on bug 2173
15:16 gmcharlt   paul: I've seen the patch - looks OK, but I want to test - hopefully later today
15:17 paul       you've seen the patch ?
15:17 paul       but hdl send it to me only. hdl, you send it to gmcharlt as well ?
15:17 thd        For a period in 2005 tried to give a fulsome answer to every koha list question without being paid but that could not last.
15:18 gmcharlt   paul: I thought it was the "restoring startsby patch on authorities" - is that the one?
15:18 paul       nope.
15:18 paul       it's the "heading-main" search one (search on heading $a)
15:18 gmcharlt   thd: flattering Koha users? nice ;)
15:24 ryan       gmcharlt: i just noticed yesterday that the '$a only' search does in fact include the entire heading.
15:25 ryan       i agree it would be useful for that to work as expected.
15:25 hdl        ryan : to reenable it, a new index should be created.
15:26 hdl        I reenabled it on UNIMARC.
15:26 thd        gmcharlt: how would 2173 be fixed for MARC 21 without searching against special local use field where names were last names would be separated like they are in UNUMARC?
15:26 hdl        But would not make it on USMARC since I donot master those DOM files enough.
15:27 thd        s/names were//
15:30 gmcharlt   thd: simplest would be to make it have a different meaning - search for base heading and ignore subdivisions - although that would not be much different from a left-anchored heading search
15:31 gmcharlt   thd: parsing first and last names is not readily supportable in MARC21, of course
15:31 thd        gmcharlt: I see yes, left anchored would work for MARC 21.
15:32 thd        gmcharlt: The comma is there for MARC 21 so last names could be parsed into a local use subfield for special treatment if needed.
15:33 gmcharlt   thd: comma is only a half measure, alas - far too many names, royal titles, and so on, would be edge cases
15:33 gmcharlt   thd: on other hand, I'm not sure that a first name search is necessarily needed, at least for staff and cataloging purposes
15:34 thd        gmcharlt: Titles etc. already have their own subfields in both MARC 21 and UNIMARC.
15:35 gmcharlt   thd: 100  	0#$aGustaf$bV,$cKing of Sweden,$d1858-1950 - where's the comma to identify the first name, e.g.,
15:36 thd        gmcharlt: Is the same code used for finding the authorised form to use in the OPAC when invoking the [...].
15:36 ryan       i was referring, btw, only to the fact that if I search on King in the field marked '$a only' , i'll get gmcharlt's example there in my results.
15:37 ryan       i don't see a need to add further indexes on subsets of $a.
15:37 thd        gmcharlt: in that case by AACR2 the first name is the most important and the last name is seldom known by searchers.
15:39 thd        ryan: If that was the issue then left anchoring on the whole field for names should solve the problem
15:41 ryan       Ah, I see.
15:42 ryan       The template then needs to be reworded if that's the solution.
15:43 hdl        for UNIMARC it is not a solution thogh.
15:43 hdl        Our users wants to be able to search on Main Entry.
15:44 hdl        But I already posted a patch for that on our sied.
15:44 hdl        I can send it to you if you want to have a look at it.
15:45 gmcharlt   thd, ryan, hdl: left-anchored is enough for MARC21, so can make searchboxes different for UNIMARC and MARC21
15:45 ryan       yes, I follow now.  I haven't looked at the dom indexing definition yet.
15:45 gmcharlt   hdl: please send me the patch if you haven't already
15:45 paul       gmcharlt: I did it 10mn ago ;-)
15:45 gmcharlt   paul: ok, it's *that* one ;)
15:45 ryan       gmcharlt: i'm fine with that approach.  as long as the interface does what it says i'm happy :)
15:45 paul       (although it's a fw: maybe a direct mail would be easier to deal with)
15:46 gmcharlt   paul: no, it's fine, git-am is smart enough to deal with it
15:47 hdl        ryan : left anchored search would be search starts by
15:47 hdl        I sent a patch for it.
15:53 paul       tinaburger: are you really here, or is it an auto-connect ?
15:53 acmoore    be not afraid, it is her!
15:58 hdl        hope you are getting better.
17:40 thd        gmcharlt: what is the last message that you have from the koha-devel list?
17:42 thd        atz: are you here?
17:53 danny      hello #koha
17:58 atz        i'm here... had to reset for OS update
18:02 thd        atz: what is the last message which you have from the koha-devel list?
18:03 atz        Thomas' reply to Koha 3.0 Stable Release Plan
18:04 thd        atz: why do I not have it.  I checked my subscription on Savannah and it seems fine.
18:05 atz        you may have to ask your email provider.
18:06 thd        atz: is a LibLime or Katipo mail system involved for koha-devel?
18:09 thd        atz: I triggered the alert for the koha users list because I do not subscribe to Koha users with the same address and hope I have not banned myself from receiving on the koha-devel list in consequence.
18:09 thd        The Koha users list was in the CC line from Joshua originally.
18:09 atz        thd:  lists.koha.org => 212.85.152.90
18:10 atz        nslookup 212.85.152.90
18:10 atz        Server:         72.36.190.2
18:10 atz        Address:        72.36.190.2#53
18:10 atz        Non-authoritative answer:
18:10 atz        90.152.85.212.in-addr.arpa      canonical name = 90.152.85.212.rev-sql.lost-oasis.net.
18:10 atz        90.152.85.212.rev-sql.lost-oasis.net    name = paulpoulain.com.
18:10 atz        so I'm guessing paul is the guy to ask on that
18:11 thd        atz: OK so if I have nothing more by Tomorrow morning I will ask paul.
18:24 hdl        thd you can ask me.
18:25 hdl        thd : I recieved you mails.
18:48 thd        hdl: The problem is that I did not receive my usual copy of y own message for the last two in reply to paul and slef
18:48 thd        s/ y/ my/
18:50 thd        hdl: mailman had caused problems for me about two years ago
18:51 thd        hdl: two years ago mailman said that I was subscribed but had stopped sending me messages.  I had to have kados fix my account at the time.
19:16 dkg        i'm trying to get koha running against perl 5.10 with CGI::Session 4.30 (debian lenny)
19:16 dkg        The installer is giving me this message:
19:16 dkg        Can't locate object method "generate_id" via package "CGI::Session::ID::" (perhaps you forgot to load "CGI::Session::ID::"?)
19:16 dkg        (i'm using koha via git, up-to-date as of this morning)
19:17 dkg        looking through the code, the only invocations of CGI::Session() use serializer:yaml.
19:18 dkg        I can coax a test perl file to fail with the same message just by creating a CGI::Session object with serializer:yaml, also, though it doesn't fail if i omit mention of a serializer.
19:18 dkg        any thoughts about what next steps to take for the debugging?
19:19 gmcharlt   dkg: sounds similar to issue reported for OpenSUSE
19:19 gmcharlt   dkg: try add Perl modules CGI::Simple and FreezeThaw
19:19 gmcharlt   dkg: also, how did you install CGI::Session - was it from CPAN or from libcgi-session-perl
19:21 dkg        libcgi-session-perl
19:21 dkg        i'll try those modules, though.
19:23 dkg        hrm.  i added those modules, but i'm still getting the same error with my test program.
19:23 dkg        and the same error with the koha installer, too.
19:24 atz        dkg: now go back and make CGI::Session again, iirc
19:25 dkg        atz: i installed via aptitude.  should i re-install?
19:26 atz        hmm... not sure there
19:27 dkg        i did "aptitude reinstall libcgi-session-perl", and my test program is still failing, so that's not it.
19:27 gmcharlt   hmm - etch has 4.15 of CGI::Session, lenny has 4.30 - perhaps 4.30 has an incompatible API change
19:29 dkg        if i modify my test program to omit the ;serializer:yaml, it seems to work fine.
19:29 hdl        dkg : I coped with that on SUN.
19:29 gmcharlt   dkg: instead of that, try adding ";id:md5" after the serializer:yaml bit
19:29 gmcharlt   per patch hdl filed today
19:29 hdl        This can be fixed with id:md5
19:30 hdl        Consider adding use CGI::Session::ID::md5 to CGI::Session if it is not enough.
19:30 atz        yeah, i saw that patch.  seems interesting.
19:31 hdl        atz : Indeed, on SUN it was vital.
19:31 dkg        if i append that to my test program, i get this error:
19:31 dkg        Can't locate object method "generate_id" via package "CGI::Session::ID::md5" (perhaps you forgot to load "CGI::Session::ID::md5"?) at /usr/share/perl5/CGI/Session.pm line 74.
19:32 dkg        but if i add "use CGI::Session::ID::md5;" to the top of the file, it completes
19:32 dkg        (with a later error message of:
19:33 dkg         (in cleanup) Can't locate object method "freeze" via package "CGI::Session::Serialize::yaml" at /usr/share/perl5/CGI/Session.pm line 241
19:33 dkg        )
19:38 dkg        hdl: do you think that this represents a bug in CGI::Session?  Should we report it to the module authors?
19:38 gmcharlt   dkg: if you then add a "use CGI::Session::Serialize::freezethaw" does it help
19:38 gmcharlt   dkg: I think it is either an API change, a bug possibly related to Perl 5.10, or perhaps a Debian packaging glitch
19:39 hdl        dkg : First, I was surpirsed that CGI::Session on CPAN was an unauthorised version.
19:39 hdl        surprised even
19:40 hdl        Second, I surely consider those things as bugs.
19:40 dkg        gmcharlt: adding "use CGI::Session::Serialize::freezethaw;" did not get rid of the "(in cleanup) Can't locate object..." error message in my test script.
19:40 hdl        But I donot know what is the reason for those bugs.
19:40 gmcharlt   dkg or hdl: could you file a bug at bugs.koha.org for this
19:41 hdl        Look at CGI::Session::Serialize::yaml
19:41 gmcharlt   it looks like it will need some time to investigate
19:41 hdl        And find if there is freeze method in this Module.
19:42 hdl        will do gm
19:44 hdl        done.
19:46 dkg        http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2216
19:46 dkg        thanks, hdl.
20:07 dkg        I just added a patch against the git head to bug 2216 that works for me to resolve the base issue (i still don't know about the "(in cleanup)" error message)
20:08 hdl        dkg : i think that that patch had just been pushed today or will soon.
20:11 dkg        hdl: excellent.
20:18 dkg        OK, so while the upgrade now works, no user session lasts more than one pageview.  I'm assuming this is because the CGI::Session object isn't properly serializing data because of the "Can't locate object..." errors.
20:18 dkg        where do i find CGI::Session::Serialize::yaml ?
20:18 dkg        it's not in /usr/share/perl5/CGI/Session/Serialize, which is where i'd usually expect it :/
20:20 gmcharlt   it would be /usr/share/perl5/CGI/Session/Serialize/yaml.pm - available in 4.14 (etch package) but not 4.30 (lenny package)
20:22 gmcharlt   dkg: ok, from CPAN changelog for CGI::Session, CGI::Session::Serialize::yaml was split out as separate module
20:22 gmcharlt   so you'll need to get it from CPAN
20:23 atz        gmcharlt: so we'll have to add that as an explicit, separate dependency
20:23 gmcharlt   atz: yes, and ask Vincent to package it
21:41 dkg        i've filed an RFP for the package in debian, fwiw:
21:41 dkg        http://bugs.debian.org/484556
21:42 dkg        i don't know who Vincent is, but if he plans on packaging it, he can close that bug in the first changelog.
21:45 gmcharlt   dkg++
21:48 dkg        (using a package built with dh-make-perl of CGI::Session::Serialize::yaml does appear to fix the problem i was having).
21:48 dkg        one more annoying question for the day:
21:49 dkg        what's the best way to do an import of 10000 marc records with roughly the same number of items?
21:49 dkg        can i do this server-side, or do i need to do it through the web ui?
21:49 gmcharlt   dkg: server-side, you can use misc/migration_tools/bulkmarcimport.pl (to load in one go)
21:50 gmcharlt   or misc/stage_biblios_file.pl and misc/commit_biblios_file.pl if you're adding records to a database that already has some and you need to handle duplicate bibs
21:50 dkg        ok, i think that makes sense.
21:50 gmcharlt   if you're using Zebra as the indexing engine, you'll then need to follow up with a rebuild_zebra.pl -b -z
21:51 dkg        is there a way to reject staged records, or do they hang around forever until you commit them?
21:51 gmcharlt   the staged records stick around
21:51 dkg        (for instance, if you realize something went wrong after staging but before commit)
21:51 gmcharlt   a delete button will be added eventually in the web UI
21:51 gmcharlt   but you can also do it from using SQL: delete from import_batches where import_batch_id = N
21:52 dkg        ah, cool.  that's great.  and that'll have no nasty side effects down the line?
21:52 gmcharlt   no side effects to deleting a staged batch pre-commit
21:52 dkg        thank you.
21:52 gmcharlt   post-commit, main effect is that you can't run the tool to undo the import
21:53 dkg        I see.
21:53 gmcharlt   but if you're doing an initial import, that's OK - bulkmarcimport.pl -d deletes all of the bibs and items if you need to start from scratch
21:54 dkg        OK, you all were a huge help for me today.  Thank you very much.
21:54 gmcharlt   you're welcome
21:54 dkg        if you're ever in NYC, i'll get you a beer (or other drink if you don't drink beer)!
21:55 gmcharlt   heh - thanks!
22:37 hdl_laptop owen around ?
22:48 hdl_laptop owen : when you read this, I was just wondering how I could get a function in Jquery used both on load and on change.
23:18 atz        hdl_laptop:   $(document).ready(function() { ... your code here ...; });
23:18 atz        then
23:21 atz        $(document).ready(function() {
23:21 atz            $('.ajax_buttons' ).css({visibility:"visible"});
23:21 atz            $('body').click(function(event) {
23:21 atz                   if ($(event.target).is('.ok')) {
23:21 atz                           $.ajax({
23:21 atz                                "data": {ok: $(event.target).attr("title"), CGISESSID: readCookie('CGISESSID')},
23:21 atz                                 "success": count_approve // success_approve
23:21 atz                            });
23:21 atz                            return false;   // cancel submit
23:21 atz                   }
23:21 atz        }
23:21 atz        so that would set up an action when the page is ready (unhiding js-dependent buttons)
23:22 atz        and also establish what would happen when a click happens on a target that has class="ok"
23:22 atz        this example is simplified from koha-tmpl/intranet-tmpl/prog/en/modules/tags/review.tmpl
23:23 atz        hdl_laptop: does that answer your question?
23:29 hdl_laptop partially.
23:29 hdl_laptop atz: I would have liked to be able to add
23:31 hdl_laptop $(frequency).change(function(){myfunction;}
23:31 hdl_laptop $(frequency).load(function(){myfunction;}
23:32 hdl_laptop add function to both change and load.
23:32 hdl_laptop If there was.
23:33 hdl_laptop seems that what you suggests suits your use. But mine is quite different.
23:34 hdl_laptop I have 2 selection fields : frequency and number patterns.
23:35 hdl_laptop And I would like to load values on load, if there are some.
23:35 hdl_laptop But maybe it is just daydreaming.
23:35 hdl_laptop (it is 1.30 here...)
23:50 atz        when you say "load" you mean when the page is first rendered
23:52 atz        in jQuery, $(document).ready means when the DOM has been built and is ready to be manipulated
23:52 atz        if you have id="frequency" on your input element, you could use:
23:53 atz        $("#frequency")....
23:56 atz        change docs: http://docs.jquery.com/Events/change
01:41 owen       Hi cnighs
01:43 cnighs     hi owen
02:09 masonj_    heya chris ;)