← Previous day | Today | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 12:12 | slef | Has anyone else had problems with Safari+Keychain and koha logins? |
| 12:12 | (I've got a fault report that I can't debug.) | |
| 12:14 | hi gaano | |
| 12:18 | gaano | hi |
| 13:02 | danny | hello #koha |
| 13:02 | slef | hello danny |
| 13:03 | hdl | hi |
| 13:05 | kados : Is there any plan to have an API to use XSLT on marcxml wherever biblios are displayed (lists, basket, acquisitions,....) ? | |
| 13:06 | Or is XSLT processing only limited to some display ? | |
| 13:19 | gmcharlt | greetings #koha |
| 13:19 | hdl: extending XSLT so that it's an option for all MARC displays is a good idea | |
| 13:20 | 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 | for instance. | |
| 13:21 | (This would help maybe for interactions.) | |
| 13:22 | 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 | 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 | hdl: I'll open a bug | |
| 13:31 | 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 | 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/m[…]RC21slimUtils.xsl - didn't find any doc per se after a minute of Google |
| 13:35 | Googling | |
| 13:36 | hdl | The fact is that we donot have anything help like that in France. |
| 13:37 | And Such functions imho are quite MARC21oriented. | |
| 13:37 | 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 | 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 | 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 | 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 | 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 | 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 | otherwise, we will continue with a local branch (as we started) | |
| 14:57 | 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 | for instance, starting a new set (aq2 tables) & C4/Acquisitions2.pm | |
| 14:58 | 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 | 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 | paul: davi is working on EDIFACT for us | |
| 15:00 | 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 | I've definitely discussed it on IRC before and I thought you were here. | |
| 15:02 | but maybe not. | |
| 15:04 | 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 | 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 | 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 | i.e., just remove JS sorter for unpaginated results | |
| 15:43 | acmoore | OK. I agree. |
| 15:44 | 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 | 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 | logbot used to speak a lot (too much) | |
| 16:20 | it make us laught often ! | |
| 16:26 | slef | !seen hdl |
| 16:26 | newlogbot: salut | |
| 16:26 | no, it's not as chatty as logbot | |
| 16:27 | hdl | !liste |
| 16:27 | !list | |
| 16:27 | paul | slef: & that's good ! |
| 16:28 | slef | ?? koha |
| 16:43 | pianohacker | newlogbot: circulation is a synonym for despair |
| 16:44 | ?? circulation | |
| 16:44 | 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 | 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 | 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 | 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 | i.e., don't rely on a perfect linear sequence | |
| 17:07 | but give each DB change an ID | |
| 17:07 | and change registry (stored in Koha DB) of which DB changes need to be applied | |
| 17:07 | check registry, that is | |
| 17:08 | some DB changes will require others as prereqs | |
| 17:08 | but may be easier for us to deal with that | |
| 17:08 | 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?[…]ment: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 | gmcharlt: thanks ;) | |
| 18:00 | 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 | 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 | 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/gi[…]a69c3869825600dea ? |
| 18:25 | gmcharlt | pianohacker: which is exactly one file |
| 18:25 | pianohacker | or http://git.koha.org/cgi-bin/gi[…]r&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 | 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 | 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 | Your mail to 'Koha' with the subject | |
| 22:21 | Re: [Koha] koha error | |
| 22:21 | Is being held until the list moderator can review it for approval. | |
| 22:21 | The reason it is being held: | |
| 22:21 | Too many recipients to the message | |
| 22:30 | atz | a reasonable spam-guard, i guess |
← Previous day | Today | Search | Index