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 ;)