| Time |
S |
Nick |
Message |
| 12:01 |
|
fbcit |
g'morning #koha |
| 12:03 |
|
paul |
hi fbcit |
| 12:39 |
|
ryan |
Can't call method "fields" on an undefined value at /opt/koha/beta/koha/C4/XSLT.pm line 59. |
| 12:39 |
|
ryan |
Did I miss an update ? |
| 12:39 |
|
ryan |
I get this error when using scan indexes in opac adv search. |
| 12:52 |
|
acmoore |
owen, you around? |
| 12:52 |
|
owen |
Yes |
| 12:53 |
|
acmoore |
Hi. I'm interested in including some links to Google Books in the opac biblio details page, and I was hoping to run it past you to see if you could help me make it look and act reasonable. |
| 12:53 |
|
acmoore |
Do you have a second for that? |
| 12:54 |
|
acmoore |
I'm not sure if you've considered this before or not, but I'm suspecting that you have some ideas. |
| 12:55 |
|
owen |
Sure, tell me about it |
| 12:55 |
|
acmoore |
well, if you pass them an ISBN or something, they'll return some JSON telling you if they have a full or partial book scanned in already. And, a thumbnail of the book cover. |
| 12:56 |
|
acmoore |
so, that looks like a possible image and one or two URLs that may be useful to add. |
| 12:56 |
|
acmoore |
Here's a quick example: http://acm.dev.kohalibrary.com[…]pl?biblionumber=8 |
| 12:57 |
|
acmoore |
notice the "information from Google" section. |
| 12:58 |
|
acmoore |
Oh, yeah. I totally hacked the implementation, so try to ignore that for a minute. But, I'm just not sure of the best way to put these things on the page (if at all). |
| 13:00 |
|
owen |
Yeah, it's a tough one. We're already putting a lot of stuff on that page |
| 13:00 |
|
owen |
But it seems like it's a good option to offer, another syspref-controlled feature |
| 13:01 |
|
owen |
It uses the greybox library? |
| 13:01 |
|
acmoore |
yeah, you'd have to be able to turn it on/off. |
| 13:01 |
|
acmoore |
Um. I have no idea what that is. |
| 13:03 |
|
acmoore |
oh, perhaps GB is for Google Books. |
| 13:04 |
|
ryan |
a google books tab ? |
| 13:06 |
|
acmoore |
Normal View | MARC View | ISBD View | Google Books |
| 13:06 |
|
acmoore |
like that? |
| 13:07 |
|
acmoore |
I can see that working. |
| 13:08 |
|
acmoore |
Or, do you mean: Holdings | Descriptions | Comments | Google Books ? |
| 13:08 |
|
owen |
I'm more inclined to go with that option... |
| 13:08 |
|
acmoore |
it does make more sense. |
| 13:08 |
|
acmoore |
in my eyes. |
| 13:09 |
|
ryan |
the latter was my thought |
| 13:10 |
|
acmoore |
that's where the amazon reviews show up, isn't it? This feels similar to that. |
| 13:10 |
|
owen |
Yeah, that's just what I was thinking |
| 13:12 |
|
acmoore |
I think we're on to something here. I'll have to look at a page with amazon reviews on it to refresh my memory. |
| 13:12 |
|
acmoore |
Any opinions on how to rearrange the image and one or two links to look reasonable? |
| 13:16 |
|
owen |
acmoore: It's interesting, because Google offers a lot of the same features we try to offer through other means on our detail page: reviews, descriptions, related |
| 13:16 |
|
owen |
It's tempting to try to pull those elements into our page in the corresponding areas, but that's probably too complicated |
| 13:17 |
|
owen |
But it would be nice to somehow express the quantity of information available from Google if people choose to click through |
| 13:18 |
|
acmoore |
yeah, I think I'm following you. |
| 13:18 |
|
acmoore |
I'm not sure that they expose that information through their API, though http://code.google.com/apis/bo[…]ting-started.html |
| 13:19 |
|
acmoore |
you can just tell if they have a cover image, and a full or partial preview, and whether there's a details page or not. |
| 13:22 |
|
owen |
I not sure I'd even show the cover... We can assume that the library is showing covers or not through other means (maybe even through Google) |
| 13:22 |
|
owen |
So really you've just got a couple of links |
| 13:22 |
|
owen |
What do you think? |
| 13:23 |
|
acmoore |
that's a good point. |
| 13:23 |
|
acmoore |
maybe these links then go in the "Online Resources" list. (MARCURLS) |
| 13:24 |
|
owen |
Yes, I think that's right. Good idea. |
| 13:24 |
|
acmoore |
though that might be deceptive or something to stuff them in there since they're not in the marc record? |
| 13:24 |
|
owen |
The patron doesn't care what is or isn't in the MARC record |
| 13:25 |
|
acmoore |
yep. That just happens to be the only place (so far) that we're searching for "online resources". is that the line of reasoning? |
| 13:26 |
|
owen |
Seems to me to be a good place to include links if we've got 'em. We can say the Amazon reviews get their own tab because we're actually pulling in the content |
| 13:28 |
|
acmoore |
I can go along with that. |
| 13:29 |
|
acmoore |
when there is no javascript, I can include a static link to the book details at google (like http://books.google.com/books?vid=ISBN0451522907 ). It may or may not exist (though I don't know what the odds are). Does that sound like a good option? |
| 13:31 |
|
owen |
I don't know... that sounds more like an option for the "Search for this title in..." box on the right |
| 13:32 |
|
owen |
We could put that link in by default and hide it with js |
| 13:33 |
|
acmoore |
I can do that. Do you mean put it in the "online resources" list and hide it with JS (and replace it with the dynamic links if they exist)? Or, do you mean put it on the right and hide it? |
| 13:34 |
|
owen |
Hard-code the link on the right, and hide it automatically, by default, with JS. |
| 13:34 |
|
acmoore |
If there is JS, and google knows about the book, one of the links that they provide is a link to that same page. It's what I've labeled with "More information from Google Books" |
| 13:35 |
|
acmoore |
so, then is the theory that if they have the javascript needed to put the links in "online resources" that they woudn't want the one on the right? |
| 13:35 |
|
acmoore |
that seems reasonable. |
| 13:36 |
|
acmoore |
Or, I can just provide the link to the scanned copy in the "online resources". and then put the link to the details page on the right. If they have no JS, the first won't show and the second will be the static link. |
| 13:37 |
|
owen |
My thought was that if they have javascript they're getting an accurate view of what Google has. The link is just "maybe Google has something on this" |
| 13:37 |
|
owen |
So the online resources link supersedes the hard-coded link |
| 13:38 |
|
acmoore |
yep. Do you think it's odd that if there's JS that the link to the details page moves from the right to the online resources section? |
| 13:42 |
|
owen |
Probably not...since people with JS turned off are going to be rare, and those people are probably /usually/ going to have it turned off |
| 13:42 |
|
acmoore |
heh. It's OK to make rampant speculations when lacking any data or evidence. |
| 13:43 |
|
acmoore |
OK. So it sounds like this plan is: 1) Ditch the image. The images are found elsewhere. |
| 13:43 |
|
gmcharlt |
I wonder if slef reguarly runs Koha with JS turned off? |
| 13:44 |
|
acmoore |
2) add a static link to the details page on the right and hide it with js. |
| 13:44 |
|
paul_ |
gmcharlt: you can be sure that yes ;-) |
| 13:44 |
|
paul |
(hello everybody) |
| 13:44 |
|
acmoore |
3) add the 1 or 2 links to the online resources section. They're built with js based on the content at google and will not be there with no js. |
| 13:44 |
|
owen |
acmoore, that sounds good to me |
| 13:54 |
|
acmoore |
OK. Thanks, guys. I'll change what I have to this and show it to you again. probably later today. |
| 15:07 |
|
acmoore |
owen, I move the links around a bit. http://acm.dev.kohalibrary.com[…]pl?biblionumber=8 |
| 15:07 |
|
acmoore |
it looks much less busy now. |
| 15:07 |
|
acmoore |
I left the link on the right visible when you have javascript on just so that it's easier to see it for now. I'll hide it later. |
| 15:08 |
|
acmoore |
If google has no preview, that link disappears: http://acm.dev.kohalibrary.com[…]pl?biblionumber=9 |
| 15:09 |
|
acmoore |
let me know if you think it's not right and I can keep monkeying with it. Otherwise, I'll clean up the code, hide that link, and submit a patch. |
| 15:09 |
|
owen |
Looks good to me |
| 15:11 |
|
frederic |
hi |
| 15:12 |
|
acmoore |
Oh, crud. If there are no MARCURLS, and no google books links, I still show the "Online Resources" section. I'll have to deal with that. |
| 15:12 |
|
acmoore |
OK. Thanks, owen. |
| 15:12 |
|
acmoore |
owen++ |
| 15:12 |
|
acmoore |
hi frederic! |
| 15:12 |
|
frederic |
acmoore: hello! |
| 15:14 |
|
owen |
acmoore: What if there are no MARCURLS but there are google links? |
| 15:16 |
|
frederic |
/tools/tools-home.pl doesn't work anymore for me. Do you have this error also? |
| 15:16 |
|
acmoore |
In my version the "online resources" sectino header is always shown. I think it should be shown if there are either MARCURLS or google books links (or both). |
| 15:17 |
|
frederic |
In log file, there is an error in C4/Auth.pm line 1296 indicating a table permission doens't exist |
| 15:18 |
|
acmoore |
frederic, what version of koha are you running? |
| 15:18 |
|
gmcharlt |
frederic: yes, that's a new table |
| 15:18 |
|
frederic |
Version 3 |
| 15:18 |
|
gmcharlt |
if you've been following v3 using git, that table should have been added via updatedatabase.pl |
| 15:18 |
|
frederic |
gmcharlt: You introduced this new table to improve permission management? |
| 15:19 |
|
gmcharlt |
ues |
| 15:19 |
|
gmcharlt |
yes |
| 15:19 |
|
frederic |
gmcharlt: I've followed the usual procedure |
| 15:19 |
|
gmcharlt |
was added in DB rev 3.00.00.068 |
| 15:19 |
|
frederic |
Thanks, I take a look |
| 15:20 |
|
gmcharlt |
ok - let me know if the updatedatabase.pl had failed to create it for some reason |
| 15:22 |
|
frederic |
gmcharlt: Will it be ok if I downgrade manually Version syspref to 067 and run by hand updatedatabase.pl? |
| 15:27 |
|
ryan |
frederic: yes, that shouldn't cause any problems |
| 15:28 |
|
frederic |
ryan: thanks! |
| 15:29 |
|
owen |
frederic: you've got your YUI upgrade |
| 15:30 |
|
frederic |
I've done it in the meantime. And it solved the problem with permission table creation. But something get wrong with upgrade to 068: Unknown 'class' in 'label_conf' |
| 15:31 |
|
frederic |
Correction: Upgrade to 069 line 1279 of updatedatabase.pl |
| 15:31 |
|
gmcharlt |
yeah - related to some work fbcit's been doing - compare your current label_conf to what's in kohastructure.sql |
| 15:33 |
|
frederic |
owen: yes! thanks. Have you seen that it doesn't work for some button? And that it necessary to modify by hand syspref yuipath if Yahoo servers are used? |
| 15:34 |
|
owen |
I haven't seen that some buttons are not working. I think someone submitted a patch that should update databases with the new preference |
| 15:34 |
|
frederic |
gmcharlt: What can explain this kind of behaviors? Am I alone to enconter those issues with upgrading DB? |
| 15:35 |
|
fbcit |
frederic: check the column names in labels_conf, most likely that column has already been renamed in your db |
| 15:35 |
|
owen |
frederic: I've had similar trouble from time to time. |
| 15:35 |
|
fbcit |
frederic: in which case you can ignore the error |
| 15:36 |
|
frederic |
owen: I'm the one who submited a patch which modify syspref yuipath for new installation (syspref default values). But the update is not done. |
| 15:36 |
|
frederic |
fbcit: ok I take a look. thanks |
| 15:36 |
|
gmcharlt |
frederic: yeah, the mechanism is a bit delicate - plus, I think there may have been a patch in the last couple weeks that corrrected a bug in updatedatabase.pl, but if you had already run the affected DB rev, may have resulted in the issue you're seeing |
| 15:36 |
|
gmcharlt |
not sure if I'm remembering corrrectly , though |
| 15:40 |
|
frederic |
fbcit: labels_conf is ok! with the 069 modification |
| 15:45 |
|
frederic |
owen: It's possible you don't see the issue if your installation yuipath points to Yahoo servers. In this case, you have to modify yupath to see the issue: substitute '2.3.1' with '2.5.1' and you will see... |
| 15:50 |
|
fbcit |
Firefox 3 also renders the koha interface nicely |
| 15:50 |
|
fbcit |
more so than Firefox 2 |
| 18:46 |
|
acmoore |
ryan, not that I disagree, but what's the problem with the .gitignore? |
| 18:46 |
|
acmoore |
I just haven't seen any problems and I don't want to get bitten by one. |
| 18:50 |
|
gmcharlt |
hmm - one issue is excluding *.iso2709, which you might want to have in test case data |
| 18:50 |
|
gmcharlt |
but excluding t/run and t/test-config.txt (per latest patches) seems like a different case |
| 18:52 |
|
gmcharlt |
per http://www.kernel.org/pub/soft[…]cs/gitignore.html, .gitignore is fine for project-level stuff (things added by build system, e.g.), user-specific stuff (i.e., removing editor cruft) should go in ~/.gitconfig's core.excludefiles |
| 18:55 |
|
atz |
acmoore: was curious about that also |
| 18:57 |
|
ryan |
acmoore: not a big deal, really, just being grumpy that I had to resolve merge conflicts in multiple repos |
| 18:58 |
|
ryan |
and sometime down the line, I imagine some conflicts with the chosen files (potentially) |
| 18:58 |
|
acmoore |
I really am not trying to argue either side here, because I don't really get what happened to you. I just don't want to happen to others (like me). Were you keeping your own .gitignore that this overwrote or something? |
| 18:59 |
|
acmoore |
I'm all for removing .gitignore if it causes more problems than it's worth. |
| 19:00 |
|
ryan |
well, reading the link gmcharlt posted, I think I have perhaps been using .gitignore incorrectly |
| 19:00 |
|
ryan |
and I should be keeping local stuff in $GIT_DIR/info/exclude |
| 19:00 |
|
gmcharlt |
per same link "*.*~" probably shouldn't be in the project .gitignore then |
| 19:01 |
|
ryan |
mostly images and small other files local to a client installation I've been keeping in .gitignore |
| 19:02 |
|
ryan |
I'm fine with a project-wide .gitignore, but I would like a policy for it |
| 19:04 |
|
gmcharlt |
ryan: an idea: .gitignore should follow whatever 'make clean' would remove |
| 19:05 |
|
ryan |
i think that would make sense |
| 19:09 |
|
ryan |
I like to keep my repos clean, and git status shows me any junk I've left behind, unless it's gitignoring a whole bunch of stuff. |
| 19:09 |
|
ryan |
just personal preference really |
| 20:32 |
|
owen |
gmcharlt: are you still around? |
| 20:32 |
|
gmcharlt |
owen: yes |
| 20:33 |
|
owen |
What was it you were unhappy with regarding your patch for bug 2019? |
| 20:34 |
|
gmcharlt |
it's that if a field like the 041 has some short subfield labels and some long ones, I'd like the input boxes to be evenly spaced, to accommodate the height caused by the longest label wrapping |
| 20:46 |
|
owen |
Okay, I see |
| 20:47 |
|
owen |
I'm not sure what can be done, but I'll take a look |
| 20:47 |
|
gmcharlt |
thanks |
| 21:36 |
|
Presently42 |
Hello. I seem to not be able to find the path to koha/koha-tmpl/intranet-tmpl/prog/en/includes. |
| 21:38 |
|
Presently42 |
I believe it should be in /usr/local/koha, but it isn't. Though I did find the /en/includes part in the cgi-bin folder of opac.... |
| 21:39 |
|
Presently42 |
Rather, I found this: /usr/local/koha/intranet/htdocs/intranet-tmpl/default/en/includes |
| 21:41 |
|
gmcharlt |
Presently42: what version? |
| 21:42 |
|
Presently42 |
2.2.9 |
| 21:45 |
|
gmcharlt |
I work more on 3.0, but I think copying /usr/local/koha/intranet/htdocs/intranet-tmpl/default/en/includes to /usr/local/koha/intranet/htdocs/intranet-tmpl/prog/en/includes should do it |
| 21:49 |
|
Presently42 |
Fair enough. I shall do so. Thank you kindly. |
| 21:51 |
|
gmcharlt |
you're welcome - good luck |
