IRC log for #koha, 2008-06-05

All times shown according to UTC.

Time S 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/
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, 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/​?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
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:[…]ery/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 .
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: =>
18:10 atz nslookup
18:10 atz Server:
18:10 atz Address:
18:10 atz Non-authoritative answer:
18:10 atz      canonical name =
18:10 atz    name =
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/ 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/ 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 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[…]w_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/ - 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
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/ (to load in one go)
21:50 gmcharlt or misc/ and misc/ 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 -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 - -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 ($('.ok')) {
23:21 atz                   $.ajax({
23:21 atz                        "data": {ok: $("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:
01:41 owen Hi cnighs
01:43 cnighs hi owen
02:09 masonj_ heya chris ;)

| Channels | #koha index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary