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