Time Nick Message 02:09 masonj_ heya chris ;) 01:43 cnighs hi owen 01:41 owen Hi cnighs 23:56 atz change docs: http://docs.jquery.com/Events/change 23:53 atz $("#frequency").... 23:52 atz if you have id="frequency" on your input element, you could use: 23:52 atz in jQuery, $(document).ready means when the DOM has been built and is ready to be manipulated 23:50 atz when you say "load" you mean when the page is first rendered 23:35 hdl_laptop (it is 1.30 here...) 23:35 hdl_laptop But maybe it is just daydreaming. 23:35 hdl_laptop And I would like to load values on load, if there are some. 23:34 hdl_laptop I have 2 selection fields : frequency and number patterns. 23:33 hdl_laptop seems that what you suggests suits your use. But mine is quite different. 23:32 hdl_laptop If there was. 23:32 hdl_laptop add function to both change and load. 23:31 hdl_laptop $(frequency).load(function(){myfunction;} 23:31 hdl_laptop $(frequency).change(function(){myfunction;} 23:29 hdl_laptop atz: I would have liked to be able to add 23:29 hdl_laptop partially. 23:23 atz hdl_laptop: does that answer your question? 23:22 atz this example is simplified from koha-tmpl/intranet-tmpl/prog/en/modules/tags/review.tmpl 23:22 atz and also establish what would happen when a click happens on a target that has class="ok" 23:21 atz so that would set up an action when the page is ready (unhiding js-dependent buttons) 23:21 atz } 23:21 atz } 23:21 atz return false; // cancel submit 23:21 atz }); 23:21 atz "success": count_approve // success_approve 23:21 atz "data": {ok: $(event.target).attr("title"), CGISESSID: readCookie('CGISESSID')}, 23:21 atz $.ajax({ 23:21 atz if ($(event.target).is('.ok')) { 23:21 atz $('body').click(function(event) { 23:21 atz $('.ajax_buttons' ).css({visibility:"visible"}); 23:21 atz $(document).ready(function() { 23:18 atz then 23:18 atz hdl_laptop: $(document).ready(function() { ... your code here ...; }); 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. 22:37 hdl_laptop owen around ? 21:55 gmcharlt heh - thanks! 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:54 gmcharlt you're welcome 21:54 dkg OK, you all were a huge help for me today. Thank you very much. 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:53 dkg I see. 21:52 gmcharlt post-commit, main effect is that you can't run the tool to undo the import 21:52 dkg thank you. 21:52 gmcharlt no side effects to deleting a staged batch pre-commit 21:52 dkg ah, cool. that's great. and that'll have no nasty side effects down the line? 21:51 gmcharlt but you can also do it from using SQL: delete from import_batches where import_batch_id = N 21:51 gmcharlt a delete button will be added eventually in the web UI 21:51 dkg (for instance, if you realize something went wrong after staging but before commit) 21:51 gmcharlt the staged records stick around 21:51 dkg is there a way to reject staged records, or do they hang around forever until you commit them? 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:50 dkg ok, i think that makes sense. 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:49 gmcharlt dkg: server-side, you can use misc/migration_tools/bulkmarcimport.pl (to load in one go) 21:49 dkg can i do this server-side, or do i need to do it through the web ui? 21:49 dkg what's the best way to do an import of 10000 marc records with roughly the same number of items? 21:48 dkg one more annoying question for the day: 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:45 gmcharlt 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:41 dkg http://bugs.debian.org/484556 21:41 dkg i've filed an RFP for the package in debian, fwiw: 20:23 gmcharlt atz: yes, and ask Vincent to package it 20:23 atz gmcharlt: so we'll have to add that as an explicit, separate dependency 20:22 gmcharlt so you'll need to get it from CPAN 20:22 gmcharlt dkg: ok, from CPAN changelog for CGI::Session, CGI::Session::Serialize::yaml was split out as separate module 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:18 dkg it's not in /usr/share/perl5/CGI/Session/Serialize, which is where i'd usually expect it :/ 20:18 dkg where do i find CGI::Session::Serialize::yaml ? 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:11 dkg hdl: excellent. 20:08 hdl dkg : i think that that patch had just been pushed today or will soon. 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) 19:46 dkg thanks, hdl. 19:46 dkg http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2216 19:44 hdl done. 19:42 hdl will do gm 19:41 hdl And find if there is freeze method in this Module. 19:41 gmcharlt it looks like it will need some time to investigate 19:41 hdl Look at CGI::Session::Serialize::yaml 19:40 gmcharlt dkg or hdl: could you file a bug at bugs.koha.org for this 19:40 hdl But I donot know what is the reason for those 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 Second, I surely consider those things as bugs. 19:39 hdl surprised even 19:39 hdl dkg : First, I was surpirsed that CGI::Session on CPAN was an unauthorised version. 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:38 gmcharlt dkg: if you then add a "use CGI::Session::Serialize::freezethaw" does it help 19:38 dkg hdl: do you think that this represents a bug in CGI::Session? Should we report it to the module authors? 19:33 dkg ) 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:32 dkg (with a later error message of: 19:32 dkg but if i add "use CGI::Session::ID::md5;" to the top of the file, it completes 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:31 dkg if i append that to my test program, i get this error: 19:31 hdl atz : Indeed, on SUN it was vital. 19:30 atz yeah, i saw that patch. seems interesting. 19:30 hdl Consider adding use CGI::Session::ID::md5 to CGI::Session if it is not enough. 19:29 hdl This can be fixed with id:md5 19:29 gmcharlt per patch hdl filed today 19:29 gmcharlt dkg: instead of that, try adding ";id:md5" after the serializer:yaml bit 19:29 hdl dkg : I coped with that on SUN. 19:29 dkg if i modify my test program to omit the ;serializer:yaml, it seems to work fine. 19:27 gmcharlt hmm - etch has 4.15 of CGI::Session, lenny has 4.30 - perhaps 4.30 has an incompatible API change 19:27 dkg i did "aptitude reinstall libcgi-session-perl", and my test program is still failing, so that's not it. 19:26 atz hmm... not sure there 19:25 dkg atz: i installed via aptitude. should i re-install? 19:24 atz dkg: now go back and make CGI::Session again, iirc 19:23 dkg and the same error with the koha installer, too. 19:23 dkg hrm. i added those modules, but i'm still getting the same error with my test program. 19:21 dkg i'll try those modules, though. 19:21 dkg libcgi-session-perl 19:19 gmcharlt dkg: also, how did you install CGI::Session - was it from CPAN or from libcgi-session-perl 19:19 gmcharlt dkg: try add Perl modules CGI::Simple and FreezeThaw 19:19 gmcharlt dkg: sounds similar to issue reported for OpenSUSE 19:18 dkg any thoughts about what next steps to take for the debugging? 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:17 dkg looking through the code, the only invocations of CGI::Session() use serializer:yaml. 19:16 dkg (i'm using koha via git, up-to-date as of this morning) 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 The installer is giving me this message: 19:16 dkg i'm trying to get koha running against perl 5.10 with CGI::Session 4.30 (debian lenny) 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. 18:50 thd hdl: mailman had caused problems for me about two years ago 18:48 thd s/ y/ my/ 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:25 hdl thd : I recieved you mails. 18:24 hdl thd you can ask me. 18:11 thd atz: OK so if I have nothing more by Tomorrow morning I will ask paul. 18:10 atz so I'm guessing paul is the guy to ask on that 18:10 atz 90.152.85.212.rev-sql.lost-oasis.net name = paulpoulain.com. 18:10 atz 90.152.85.212.in-addr.arpa canonical name = 90.152.85.212.rev-sql.lost-oasis.net. 18:10 atz Non-authoritative answer: 18:10 atz Address: 72.36.190.2#53 18:10 atz Server: 72.36.190.2 18:10 atz nslookup 212.85.152.90 18:09 atz thd: lists.koha.org => 212.85.152.90 18:09 thd The Koha users list was in the CC line from Joshua originally. 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:06 thd atz: is a LibLime or Katipo mail system involved for koha-devel? 18:05 atz you may have to ask your email provider. 18:04 thd atz: why do I not have it. I checked my subscription on Savannah and it seems fine. 18:03 atz Thomas' reply to Koha 3.0 Stable Release Plan 18:02 thd atz: what is the last message which you have from the koha-devel list? 17:58 atz i'm here... had to reset for OS update 17:53 danny hello #koha 17:42 thd atz: are you here? 17:40 thd gmcharlt: what is the last message that you have from the koha-devel list? 15:58 hdl hope you are getting better. 15:53 acmoore be not afraid, it is her! 15:53 paul tinaburger: are you really here, or is it an auto-connect ? 15:47 hdl I sent a patch for it. 15:47 hdl ryan : left anchored search would be search starts by 15:46 gmcharlt paul: no, it's fine, git-am is smart enough to deal with it 15:45 paul (although it's a fw: maybe a direct mail would be easier to deal with) 15:45 ryan gmcharlt: i'm fine with that approach. as long as the interface does what it says i'm happy :) 15:45 gmcharlt paul: ok, it's *that* one ;) 15:45 paul gmcharlt: I did it 10mn ago ;-) 15:45 gmcharlt hdl: please send me the patch if you haven't already 15:45 ryan yes, I follow now. I haven't looked at the dom indexing definition yet. 15:45 gmcharlt thd, ryan, hdl: left-anchored is enough for MARC21, so can make searchboxes different for UNIMARC and MARC21 15:44 hdl I can send it to you if you want to have a look at it. 15:44 hdl But I already posted a patch for that on our sied. 15:43 hdl Our users wants to be able to search on Main Entry. 15:43 hdl for UNIMARC it is not a solution thogh. 15:42 ryan The template then needs to be reworded if that's the solution. 15:41 ryan Ah, I see. 15:39 thd ryan: If that was the issue then left anchoring on the whole field for names should solve the problem 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:37 ryan i don't see a need to add further indexes on subsets of $a. 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:36 thd gmcharlt: Is the same code used for finding the authorised form to use in the OPAC when invoking the [...]. 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:34 thd gmcharlt: Titles etc. already have their own subfields in both MARC 21 and UNIMARC. 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:33 gmcharlt thd: comma is only a half measure, alas - far too many names, royal titles, and so on, would be edge cases 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:31 thd gmcharlt: I see yes, left anchored would work for MARC 21. 15:31 gmcharlt thd: parsing first and last names is not readily supportable in MARC21, of course 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:27 thd s/names were// 15:26 hdl But would not make it on USMARC since I donot master those DOM files enough. 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 I reenabled it on UNIMARC. 15:25 hdl ryan : to reenable it, a new index should be created. 15:25 ryan i agree it would be useful for that to work as expected. 15:24 ryan gmcharlt: i just noticed yesterday that the '$a only' search does in fact include the entire heading. 15:18 gmcharlt thd: flattering Koha users? nice ;) 15:18 paul it's the "heading-main" search one (search on heading $a) 15:18 paul nope. 15:18 gmcharlt paul: I thought it was the "restoring startsby patch on authorities" - is that the one? 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:17 paul but hdl send it to me only. hdl, you send it to gmcharlt as well ? 15:17 paul you've seen the patch ? 15:16 gmcharlt paul: I've seen the patch - looks OK, but I want to test - hopefully later today 15:16 paul hi gmcharlt. Pls note my comment on bug 2173 15:15 owen Generally the koha list can be considered the koha-install list 15:14 thd being unpaid: I sadly no longer read the koha list 15:13 gmcharlt ;) 15:13 gmcharlt atz: heh - at least we're paid, in effect, to be on it 15:13 atz lol gmcharlt : you know, sometimes I want to escape from the koha list, too. 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:11 owen Which is why it might be good to convert all inputs to single-row textareas and make them automatically resizeable 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:09 owen But my point stands: I wouldn't even want to have to edit 255 characters from a single line input field 15:08 thd owen: 99999 is merely the theoretical maximum for the standard :) 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:05 thd ... for addbiblio.pl . 15:05 thd owen: I propose that 255 be changed to 99999 to avoid a data loss risk. 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:03 nengard ehe 14:59 hdl lol 14:58 gmcharlt owen: it's a requirement of PhD to sign a blood oath to entitle all monographs that way 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:52 nengard heh 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: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:47 nengard thd - i've seen those long titles today :) hehe 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:39 thd s/know/be trusted/ 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:37 paul one day, /me will find some time to investigate jquery a lot... 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:36 owen jquery++ :) 14:35 hdl owen : COOOL ;) 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:32 owen You could even auto-resize your textareas: http://zivotdesign.com/examples/jquery/textarea.html 14:32 nengard paul - let me start over 14:32 nengard oh - i was editing a biblio 14:32 nengard sorry - 520 $a on addbiblio.pl 14:31 paul nengard: what do you mean by "it" ? 14:21 nengard is there anyway to make it always a textarea? 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:20 thd paul: I see 255 for some notes fields at least 14:19 paul + all notes fields are automatically set to textarea 14:19 thd owen: I see maxlength 255 everywhere 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 owen maxlength only applies to input type="text" 14:19 owen If it's a textarea, then there isn't a maxlength 14:18 nengard this - after i hit submit 14:18 nengard ation 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 520 -SUMMARY, ETC. 14:18 nengard a Bibliography, etc Includes bibliographical references and indexes. 14:18 nengard 504 -BIBLIOGRAPHY, ETC. NOTE 14:17 nengard ..... 14:17 nengard but it worked 14:17 nengard no idea :) 14:17 nengard LOL 14:17 thd nengard: how did you fit 400 characters into a field defined as maxlength 255? 14:14 hdl yes 14:12 mc 30 my $debug_level = C4::Context->preference("DebugLevel"); 14:12 mc hdl, are you talking about this line : 14:08 hdl it is what ? 14:08 hdl Can you detail ? 14:07 mc and it is! 14:07 mc hdl: i just verified with a simple code 14:06 atz sorry, on conf. call..... bbl 14:05 hdl atz ? 14:05 mc so you can't use C4::Context in the C4::Context's BEGIN 14:04 mc bytecoding 14:04 mc when bytecodinf 14:04 mc hdl: peraps it's time for me to read the perldoc again but BEGIN block is executed asap 14:03 mc (right at the frontier, in fact) 14:03 mc near germany 14:03 mc strasbourg 14:03 mc thd, yep 14:03 thd mc: do you live in France? 14:02 mc thx, hdl 14:02 hdl mc: thd is american and worked on MARC21 frameworks. he is really helpful in general use cases. 14:01 owen thd: view source on the Add MARC page to see 14:01 hdl thd : mc is a BibLibre man. 14:01 thd hello mc 14:00 mc hello all 14:00 hdl 5.8.5 14:00 atz what version of perl? 14:00 atz hdl: interesting 13:59 hdl atz : asking it because on SUN it threw me out. 13:59 atz hdl: does that make sense re: Context? 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:58 atz that *sub* uses ->preference, but the sub itself will not be called until after the BEGIN block. 13:57 nengard thd++ 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 atz see what is happening is that the sub "handle_errors" is being defined 13:57 nengard here's the edit URL: koha/cataloguing/addbiblio.pl?biblionumber=263&op= 13:57 atz hdl: it is an unusual exceptional case 13:57 nengard i got over 400 characters into the field when editing 13:56 nengard thd hdl atz - i just tested in the newest version i have and it is not limited 13:56 owen There are several instances of 'maxlength="255"' in addbiblio.pl, which I assume correspond to database field limits 13:56 hdl Is it allowed ?* 13:56 hdl atz : it is quite puzzling for me that C4::Context could use C4::Context->preference in its BEGIN block. 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:54 nengard oh 13:54 thd nengard: no I mean that I did not test it 13:53 nengard it has been a while - let me go try to edit a record .... 13:53 nengard thd - maybe it cut it off after i submitted it - or maybe it has been fixed 13:53 thd nengard: I did not see this bug myself. Which Koha editor does it affect? 13:52 nengard atz koha/cataloguing/addbiblio.pl?frameworkcode=BKS 13:52 atz nengard: can you give a URL so I know what page to look at? 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:51 hdl Would that be enough for you ? 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 thd : Some notes fields in UNIMARC are Textarea notes and not input fields. 13:51 atz 134 is a weird number indeed 13:50 nengard atz - off to read it 13:50 atz or nengard, perhaps you can elaborate? 13:49 atz thd: i don't know about #2095. that seems odd. can you give a URL? 13:47 atz *text 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 thd atz hdl: if the templates are not the cause of bug #2095 then what would be? 13:47 atz thd: that sounds more feasible 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: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:39 atz right 13:39 atz i'm saying we might be able to use this selectively, rather than with every input field 13:39 thd atz: I see for a small number deemed liable to change 13:39 atz the dynamic approach 13:38 thd atz: which approach? 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 atz for specific fields that we consider more volatile, we might be able to take this approach relatively soon 13:35 atz of course revising the structure that broadly would require an enormous number of changes 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:33 atz the examples cited are either problems that are already fixed, or ones that *might* occur later 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 how is this problem critical? 13:32 atz not to mention it keeps your server from getting overrun 13:32 atz because the *limit* could be valid. 13:31 thd atz: the intention was to make Koha easier to customise but why should the interface limit valid data? 13:31 nengard thanks hdl 13:31 hdl nengard: yes 13:30 nengard just want to confirm that this sys pref 'RoutingSerials' is talking about serials routing lists? 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 thd owen: OK 13:29 owen thd: no, not as far as I know 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 thd owen: is 2095 not a template issue? 13:29 owen thd, your comments are much better addressed to atz and hdl, since you're not talking about a template issue 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:26 thd owen: #2095 may be a currently problematic instance. 13:26 thd atz: I mention 2 in bug #2189 as mere examples. Any where enlarging would suit a local need. 13:24 atz what fields, specifically, do we think any library would be interested to enlarge? 13:24 thd build them whenever the database changes 13:23 thd non-real-time auto-building 13:23 thd not that that would happen any time soon 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:21 atz it is perfectly valid for a DB field to have capacity greater than the interface makes use of 13:20 atz the cataloging module in particular would drag incredibly 13:20 thd owen: because it is self validating and allows changes when necessary 13:20 hdl this would really be MUCH proc-intensive. 13:20 thd hello hdl 13:19 owen Why? Because you suspect libraries will be changing the size of their database fields? 13:19 atz thd: that does not sound very reasonable 13:19 hdl nice to see you 13:19 hdl thd: hi 13:19 thd owen: my suggestion is to calculate it in real time from the database maximum for the particular field 13:18 owen Yes 13:18 thd owen: then it is hard coded as I had presumed? 13:17 owen No 13:17 thd owen: are you saying that maxlenghth is currently read from the database limit for that field in real time? 13:15 owen Unless you're finding that the database field allows enough characters but the form field maxlength is smaller 13:15 owen The maxlength attribute should reflect the maximum number of characters allowed by the database field 13:14 thd owen: the maxlength value is hardcoded when it need not be 13:14 thd owen: exactly it is the maxlength value which causes the problem 13:13 owen The templates just have a maxlength attribute applied to the input tag 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:12 thd owen: what then restricts the ability to enter more than a given set of characters in a Koha for field? 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:10 thd owen: I did not look to see where the problem was I only guessed 13:07 owen The database is not configured to match form field sizes 13:07 owen The templates are generally set up to match field sizes in the databases 13:07 owen knowledge is the hard coding in the templates." 13:07 owen "The only Koha code which restricts the size of organisation codes to my 13:06 thd owen: although one current bug is directly caused by it perhaps 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:03 owen thd, is the primary issue of 2189 that of database field sizes? 13:02 thd 2189 13:02 thd another always existed 13:02 owen ? 13:01 thd s/#2\d+/#2189/ # tubule tying today 13:01 owen Bug 2169 has *always* existed, as far as I know. 13:01 owen I would like to see Bug 2169 fixed just as much as you, but it's outside of my expertise. 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. 12:59 owen thd, do you mean 2189? 12:58 owen 218? 12:58 thd owen: will bug #218 be on your itinerary in future? 12:55 owen All of them, I think. He had a huge itinerary 12:55 thd owen: which road is that? 12:54 owen kados is on the road, thd, so I don't know if you'll be able to catch him 12:51 thd kados ping 12:42 nengard ok 12:42 nengard ah - but it should still be an empty string? 12:42 owen So it's a minor bug 12:41 owen I think no, because the template system will interpret "0" the same as "empty." 12:41 nengard i am just a bug magnet 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 owen - oops - here's my full question 12:39 owen If so, nengard, then you're right--that's a bug. 12:39 nengard hey all - sys pref question - shouldn't OPACUserCSS default to '' ? Right now it's defaulting to '0' ... isn't 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??