Time Nick Message 12:12 slef Has anyone else had problems with Safari+Keychain and koha logins? 12:12 slef (I've got a fault report that I can't debug.) 12:14 slef hi gaano 12:18 gaano hi 13:02 danny hello #koha 13:02 slef hello danny 13:03 hdl hi 13:05 hdl kados : Is there any plan to have an API to use XSLT on marcxml wherever biblios are displayed (lists, basket, acquisitions,....) ? 13:06 hdl Or is XSLT processing only limited to some display ? 13:19 gmcharlt greetings #koha 13:19 gmcharlt hdl: extending XSLT so that it's an option for all MARC displays is a good idea 13:20 gmcharlt hdl: we don't have any specific plans, yet, but we should definitely explore it for 3.2 13:20 hdl I thought we could even have a web API for that 13:21 gmcharlt yep 13:21 hdl xslt/xsltname/biblio/biblionumber1/biblionumber2/bibnumber3. 13:21 hdl for instance. 13:21 hdl (This would help maybe for interactions.) 13:22 hdl I asked that because I was working on recentacquisitions and I wanted to use an XSLT. But seems that none could be used. 13:23 hdl gmcharlt: Is there someone that could explain some of the utils functions in XSLT ? 13:30 gmcharlt hdl: hmm, yeah, the POD there is a little lacking 13:30 gmcharlt hdl: I'll open a bug 13:31 gmcharlt hdl: actually, wait - to clarify, are you asking about C4::XSLT or the utility functions called in the XSLT stylesheet itself 13:31 slef Has anyone else had problems with Safari+Keychain and koha logins? 13:31 hdl the XSLT stylesheet itself. 13:32 slef Oh sorry, I already aksed that. 13:32 slef asked 13:32 gmcharlt slef: not that I've noticed, but I use FF3 much more than Safari when working with Koha on my Mac 13:33 nicomo slef : I use safari+Keychain; never encountered any problem so far 13:34 hdl ryan: ? 13:35 gmcharlt hdl: the utility functions are from http://www.loc.gov/standards/marcxml/xslt/MARC21slimUtils.xsl - didn't find any doc per se after a minute of Google 13:35 gmcharlt Googling 13:36 hdl The fact is that we donot have anything help like that in France. 13:37 hdl And Such functions imho are quite MARC21oriented. 13:37 hdl So I tried to understand (months ago) the importance of such functions. 13:38 gmcharlt the ones in that stylesheet seem pretty generic, except for chopPunctuation, which I assume is mostly redundant in UNIMARC 13:45 hdl gmcharlt: seems that order of subfields is important and UNIMARC subfield order is not the same. 13:46 gmcharlt hdl: wrt to what? subfieldSelect preserves the order; you just tell it which ones you're interested in 13:51 hdl yes : was wrt specialSubfieldSelect 13:55 gmcharlt hdl: ah, I see, that's in the /MARC21slim2OPACDetail.xsl, not the more generic utility functions 13:55 owen Speaking of XSLT, does anyone know why my XSLT version of opac-detail isn't displaying any data? 13:56 owen I've got the pref turned on. Is there something else I need to do? 13:56 hdl you should point to the good xslt files in some sys prefs. 13:57 hdl gmcharlt: yes, was quite an old memories fo mine. 13:57 owen hdl, the only XSLT prefs I have are for DetailsDisplay and ResultsDisplay 13:57 gmcharlt owen: anything in log? 13:58 owen Doesn't look like it 14:54 paul gmcharlt: 2 weeks ago (iirc), kados told us you were away, so he won't create a new branch for 3.2. Now you're back. I think it could be usefull to create 3.2 now 14:54 paul your opinion ? 14:54 gmcharlt paul: as a temporary branch, maybe OK 14:54 paul what do you mean by "temporary branch" ? 14:55 gmcharlt paul: ideally, once we fully transition to 3.2 14:55 gmcharlt I'd want 3.2 patches to go to HEAD 14:55 paul then, it's time to branch 3.0 maybe ;-) 14:55 gmcharlt and stuff for 3.0.1 to go on a 3.0-post-final maint branch 14:56 gmcharlt paul: I take it you have a bunch of 3.2 patches lined up? 14:57 paul monday, a new BibLibrer will start working on new acquisition module with Olivier. So I would be pleased to have a branch to commit into. to share the work with you 14:57 paul otherwise, we will continue with a local branch (as we started) 14:57 paul that's possible, but not optimized I think 14:57 gmcharlt for the new acq module, are you changing C4::Acquistions, or starting an entirely new set of DB tables and modules? 14:57 paul + some patches should not be added to head now, and it's a shame to have them pending for weeks/months. 14:58 paul for instance, starting a new set (aq2 tables) & C4/Acquisitions2.pm 14:58 paul but i'm not sure it's the best solution, we may want to switch 14:58 slef huh? new acq module? 14:59 paul example of a patch that should not be in 3.0, but in 3.2 = Joe, jul 14:59 paul example of a patch that should not be in 3.0, but in 3.2 = Joe, jul 30, "Tag cloud implementation in jquery" 14:59 slef paul: can we coordinate so the EDIFACT stuff still works with it, please? 14:59 paul "still works " ? 14:59 slef #include <rants/javascript.die.die.die> 15:00 slef paul: davi is working on EDIFACT for us 15:00 slef paul: I hope it will work this autumn, if our suppliers start to cooperate and give us test accounts. 15:00 davi slef, yes 15:00 paul mmm... is your code available somewhere ? 15:00 slef davi: I'll chase again today 15:01 davi great! 15:01 slef paul: nafaik... later 15:01 paul did you announce it on koha-devel ? 15:01 slef paul: actually, I'm not sure. It should be in bugs.k.o at least. 15:02 slef I've definitely discussed it on IRC before and I thought you were here. 15:02 slef but maybe not. 15:04 slef paul: it was >9 months ago 15:07 paul ok, thanks. I've cced olivier that works on our part. I hope i'll be able to open our git in early sept. 15:08 slef biab 15:10 atz paul: actually that was part of the tags specs I was working from, so 3.0 or 3.2, i had to do it now 15:11 paul atz: OK, but if it's not added to HEAD now, it will stay pending nowhere until 3.2 is branched. 15:30 slef Real men do not play games, they win! 15:30 slef spam is funny 15:30 acmoore gmcharlt: If I look at getting 2084 knocked out for the 3.0 release, do you think I should disallow sorting on those large results, or allow it after a warning, or what? 15:31 atz i think the absurdist poets would be stunned at the quality of spam's nonsense 15:32 gmcharlt slef: I've also noticed that spam subject lines have actually gotten pretty funny in the last month or two 15:32 slef acmoore: you're going to knock 2084 out? Careful! Knocking one out too often makes you go blind... 15:33 gmcharlt we have yet to install the haptics interface to bugzilla, so hopefully acmoore will survive :) 15:34 slef gmcharlt: I still think dehydration would be a danger. 15:37 gmcharlt acmoore: basically, I think that if a report can reasonably have more than 200 rows or so for a large library, the JS table-sorter should be removed for now 15:37 gmcharlt acmoore: not best in the long run, but useful for now 15:38 slef ok, who turned on the sky-taps? 15:39 acmoore so, we would still return all of the data, but withouth the JS sorter, right? 15:41 gmcharlt acmoore: right 15:43 acmoore Do you think it's worth testing the database to see if it has a large amount of data, or just remove the JS sorter for those places where users *could* have a lot of data? 15:43 gmcharlt for now, simple is best IMO 15:43 gmcharlt i.e., just remove JS sorter for unpaginated results 15:43 acmoore OK. I agree. 15:44 acmoore OK, I'll look into it a bit and see how I do. 15:46 atz acmoore: should be able to handle the number of results in the template and optionally load or skip the sorter 15:46 pianohacker Couldn't we hook the current table sorter interface up to ajax for 3.2? 15:46 acmoore atz: good point. count the @results in the template and pass a flag to enable or disable the sorter? 15:47 pianohacker I.e., re-load and cache the results when you sort differently 15:47 atz acmoore: right 15:47 atz pianohacker: yeah, ideally just pushing JSON to AJAX... very application-y 15:51 gmcharlt atz, pianohacker: good idea for 3.2 15:51 pianohacker gmcharlt: You probably have a keyboard shortcut to say that at this point 16:19 paul newlogbot: seen hdl ? 16:19 pianohacker paul: I don't think newlogbot is quite that smart 16:20 paul I thought ;-) 16:20 paul logbot used to speak a lot (too much) 16:20 paul it make us laught often ! 16:26 slef !seen hdl 16:26 slef newlogbot: salut 16:26 slef no, it's not as chatty as logbot 16:27 hdl !liste 16:27 hdl !list 16:27 paul slef: & that's good ! 16:28 slef ?? koha 16:43 pianohacker newlogbot: circulation is a synonym for despair 16:44 pianohacker ?? circulation 16:44 pianohacker Dang 16:44 slef pianohacker: /msg newlogbot !define <word> <definition> 16:44 pianohacker Ah 17:02 acmoore pianohacker: was it you talking about possibly doing something to facilitate picking database version numbers? 17:02 pianohacker Yes 17:02 acmoore I'm wondering if you have a plan that I should participate in. 17:02 pianohacker I was thinking just creating a namespace on the wiki and posting a message to koha-devel 17:03 pianohacker i.e., development:dbrevs:v106 17:03 acmoore that might work. So, if I'm writing a feature now that I don't expect to be done for a few days, how would I determine which database number to pick? 17:03 acmoore I think I'd want to keep them in order, so if I picked the next available number, someone else might get a commit in sooner than me, using a larger number. 17:04 gmcharlt picking DB rev number would be one's last act before submitting 17:04 gmcharlt gaps in sequence would be OK, if untidy 17:04 acmoore ah. 17:04 gmcharlt but out-of-order changes would break things 17:06 acmoore yeah, it sure would. 17:07 gmcharlt maybe a sort of DB change registry might be better 17:07 gmcharlt i.e., don't rely on a perfect linear sequence 17:07 gmcharlt but give each DB change an ID 17:07 gmcharlt and change registry (stored in Koha DB) of which DB changes need to be applied 17:07 gmcharlt check registry, that is 17:08 gmcharlt some DB changes will require others as prereqs 17:08 gmcharlt but may be easier for us to deal with that 17:08 gmcharlt dunno 17:08 slef directed graphs yay! 17:09 rhcl When will kados et al be back from Kansas? I assume that's where he's at, anyway. 17:09 gmcharlt rch1: he'll be fully back by Monday (US) 17:09 rhcl OK, tnx. 17:36 pianohacker Could everybody take a look at http://wiki.koha.org/doku.php?id=en:development:dbrevs:start and give me an opinion? 17:58 acmoore pianohacker: I'm not sure that the 2 day wait in this new process is going to make it worth the benefit of possibly having to send a patch again. 17:59 pianohacker english.py: RuntimeError: too much recursion 18:00 gmcharlt pianohacker: translation - it would slow things down too much 18:00 pianohacker Ah 18:00 pianohacker gmcharlt: thanks ;) 18:00 pianohacker That was mainly thrown in there so that changes would get bundled together; I can remove it if it would be a problem 18:01 gmcharlt pianohacker: also, could you put a big fat "this is only a proposal" on the wiki page 18:01 acmoore oh yeah, I guess I said that backwards. sorry. 18:05 pianohacker Okay, edited 18:15 owen Are the help files in intranet-tmpl/prog/en/modules/help getting generated by something? 18:18 acmoore pianohacker: I edited it. Is that how you pictured it? 18:20 pianohacker Very much so! 18:21 pianohacker owen: nengard is editing them, that might be it 18:22 acmoore I can see this being useful, but it's still quite a bit of work to do. In fact, I'm not really sure that the subpage is necessary once I've put my name, a date, a version number, and a bug number there. 18:23 pianohacker That's a good point 18:23 pianohacker Maybe not bother with the subpage, and instead make the description on the main page slightly more detailed? 18:24 gmcharlt pianohacker, owen: as far as I know, nengard has not in fact submitted any patches to the help files yet - it must be something else 18:24 pianohacker http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commit;h=480f329c96e1dfe750ed8e6a69c3869825600dea ? 18:25 gmcharlt pianohacker: which is exactly one file 18:25 pianohacker or http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha&a=search&h=480f329c96e1dfe750ed8e6a69c3869825600dea&st=author&s=Nicole+Engard 18:26 gmcharlt pianohacker: I stand corrected 18:29 acmoore pianohacker: I added a table. Maybe that will suffice? I guess if more discussion is warranted, the version number can be a link a subpage if it exists? 18:30 pianohacker Sounds good 18:31 acmoore I hope I haven't railroaded your suggestion. 18:33 pianohacker No, this is good 18:34 pianohacker Edited again, hopefully my long sentences fetish won't annoy anybody 18:36 acmoore OK, I made my version number into a link, for demonstration purposes, I guess. 18:38 acmoore This might actually be handy if we start to use it. I'm interseted in seeing what kind of reaction you get from the koha-devel list. 18:40 pianohacker <shiver> 22:21 cnighs interesting 22:21 cnighs Your mail to 'Koha' with the subject 22:21 cnighs Re: [Koha] koha error 22:21 cnighs Is being held until the list moderator can review it for approval. 22:21 cnighs The reason it is being held: 22:21 cnighs Too many recipients to the message 22:30 atz a reasonable spam-guard, i guess