IRC log for #koha, 2008-04-19

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time 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 Did I miss an update ?
12:39 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 Do you have a second for that?
12:54 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 so, that looks like a possible image and one or two URLs that may be useful to add.
12:56 Here's a quick example: http://acm.dev.kohalibrary.com[…]pl?biblionumber=8
12:57 notice the "information from Google" section.
12:58 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 But it seems like it's a good option to offer, another syspref-controlled feature
13:01 It uses the greybox library?
13:01 acmoore yeah, you'd have to be able to turn it on/off.
13:01 Um. I have no idea what that is.
13:03 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 like that?
13:07 I can see that working.
13:08 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 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 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 It's tempting to try to pull those elements into our page in the corresponding areas, but that's probably too complicated
13:17 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 I'm not sure that they expose that information through their API, though http://code.google.com/apis/bo[…]ting-started.html
13:19 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 So really you've just got a couple of links
13:22 What do you think?
13:23 acmoore that's a good point.
13:23 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 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 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 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 that seems reasonable.
13:36 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 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 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 owen, I move the links around a bit. http://acm.dev.kohalibrary.com[…]pl?biblionumber=8
15:07 it looks much less busy now.
15:07 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 If google has no preview, that link disappears: http://acm.dev.kohalibrary.com[…]pl?biblionumber=9
15:09 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 OK. Thanks, owen.
15:12 owen++
15:12 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 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 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 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 not sure if I'm remembering corrrectly , though
15:40 frederic fbcit: labels_conf is ok! with the 069 modification
15:45 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 more so than Firefox 2
18:46 acmoore ryan, not that I disagree, but what's the problem with the .gitignore?
18:46 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 but excluding t/run and t/test-config.txt (per latest patches) seems like a different case
18:52 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 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 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 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 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 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 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 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 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 Rather, I found this: /usr/local/koha/intranet/htdocs/i​ntranet-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/i​ntranet-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

← Previous day | Today | Next day → | Search | Index

koha1