| Time |
S |
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/m[…]RC21slimUtils.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?[…]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 |
|
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/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 |
|
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 |
