IRC log for #koha, 2009-08-13

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

All times shown according to UTC.

Time Nick Message
12:30 chris_n g'morning
12:33 gmcharlt bbiab
12:59 owen Most of the templates have been tidied at some point, but then entropy seems to take hold
13:04 jwagner A week or two ago I was asking about MARC to Koha mapping for something, and the general response was that trying to modify the Koha to MARC mapping by repurposing an existing mapping to a new field would be A Bad Idea.  What about editing an existing field?
13:05 Right now, title is mapped to 245a.  I'd like to expand that to be 245a,b,h and maybe n & p.  Is that possible/advisable?
13:06 gmcharlt currently only pulls from one subfield
13:06 there's some work nahuel is poking at to expand that
13:07 jwagner The goal here is to make a more complete title show in various reports, like holds to pull, which when you say "title" currently only display 245a.  I couldn't see any good way to do that from the other end (report code), but maybe I'm missing something there.
13:13 gmcharlt mapping multiple subfields is the cheapest way of doing it, especially for reporting display purpose
13:13 *purposes
13:14 jwagner mapping multiple subfields where -- in the Koha to MARC mapping? In the report code?
13:14 chris_n owen: is there a widely accepted tidy config to use on the template files?
13:15 owen I've never tried tidying the actual tmpl files. I just try to do thorough validation on the resulting pages
13:15 chris_n I was thinking of indentation, etc. for greater readability
13:16 some of them are a regular rat's nest :-)
13:17 owen True...but one thing to consider is that whitespace in and around TMPL tags creates whitespace in the resulting HTML, which in turn creates larger file size
13:17 So sometimes it's worth keeping things compact
13:19 chris_n true
13:21 hdl_laptop gmcharlt: should I send you an updatedatabase for new_acq or can I commit that somehere  ?
13:21 Already up on koha_biblibre
13:21 but maybe you want to test.
13:21 gmcharlt hdl_laptop: picking from the branch is fine
13:22 hdl_laptop: what would be nice is if you could squash the individual updates into a smaller set
13:22 hdl_laptop atomic update you mean ?
13:22 Or individual commits ?
13:22 gmcharlt and to be sure - koha_biblibre = git.koha.org/koha-biblibre.git  or your internal repo?
13:23 hdl_laptop git.koha.org/koha-biblibre.git
13:23 gmcharlt hdl_laptop: atomic update would be good, but what I meant is squashing the individual udpates into fewer parts
13:23 i.e., if there were 3 changes adding columns to budgets (for example), make it one
13:24 hdl_laptop gitosis was what prevented me from doing that...
13:24 chris_n owen: has the use of Apache::Dynagzip  ever been considered?
13:24 owen I don't know
13:24 hdl_laptop can't squash easily
13:24 chris_n: apache mod_deflate ?
13:25 gmcharlt hdl_laptop: sorry, I used "squash" imprecisely
13:25 chris_n hdl_laptop: I have not looked at that
13:25 gmcharlt not in the sense of squashing git commits
13:25 but doing a further commits that updates the current set of udpatedatabase entries for new_acq
13:25 into a smaller, more logically coherent set
13:26 chris_n hdl_laptop: owen just got me wondering what performance gain could be had using some sort of compression on the outbound html
13:27 gmcharlt chris_n: mod_deflate is probably the quickest win
13:28 hdl_laptop gmcharlt: I have http://git.koha.org/cgi-bin/gi[…]9dd7d7e3984b81414
13:29 This one has three folowups
13:31 gmcharlt jumping from 3.0.3 to 3.1.0.110 - odd
13:31 but anyway, it does look like the new_acq updates
13:32 have been consolidated, so thanks
13:32 doe
13:32 does
13:32 2614 # SORRY , NO AQBUDGET/AQBOOKFUND -> AQBUDGETS IMPORT JUST YET,
13:32 2615 # BUT A NEW CLEAN AQBUDGETS TABLE CREATE FOR NOW..
13:32 still apply?
13:32 or is that handled by the followups?
13:36 hdl_laptop not handled
13:36 sorry.
13:36 It is handled.
13:36 The comments are vetigual
13:37 vestigual
13:37 even
13:40 owen What is the purpose of the z39.50 search button on the staff client detail page?
13:41 Can someone explain what workflow that fits into?
13:49 gmcharlt: git blame tells me to ask you
13:49 gmcharlt owen: in meeting, just a moment
13:49 owen np
13:58 collum hi owen
13:58 gmcharlt owen: idea is that if you're a cataloger in a consortium and looking for a bib to attach your item to, if you don't find the bib you want, you can immediately strigger a Z39.50 search
13:59 owen So you're looking at a title in the catalogue, but it's *not* the one you want. So you want to jump to z39.50 to start the addbiblio process.
14:00 gmcharlt right
14:00 owen So it would be logical to wrap it in <!-- TMPL_IF NAME="CAN_user_editcatalogue" --> ?
14:00 gmcharlt yes
14:01 wizzyrea owen++ for fixing something we noted but hadn't yet reported
14:01 :)
14:02 arg got to get out of this office before I get trapped by another. pho... too late
14:06 jwagner owen, since you're looking at z39.50 (tangentially, at least), where would I find the code that says always open a z39.50 search in a new window?  I want to make that go from a small window to a maximized window.  Haven't found it so far in Z3950.pm or z3950_search.pl, but I'm not quite sure what I'm looking for.
14:06 collum owen: I just saw your patch changing 'request' to 'hold' is there a list somewhere of terms that should be used.
14:07 owen jwagner: pop-up windows are triggered via JavaScript, which is client-side. So you'd have to look for it in templates or includes
14:07 collum: Unfortunately no.
14:08 It used to be a real mish-mash, which you can tell just by the file names and preferences.
14:08 jwagner Hrmm.  Well, I started with z3950_search.tmpl but didn't spot anything there.  Let me take a closer look.
14:08 collum owen:  ok, too bad.
14:08 -- for instance, we librarians cannot decide what to call the people who use the library --
14:08 gmcharlt collum: http://lu.com/odlis/index.cfm can provide some guidance
14:08 owen jwagner: sure, but z3950_search.tmpl is the template you get *after* the window is triggered.
14:08 collum gmcharlt: thanks
14:09 owen Look for what link/button *triggers* the pop up
14:09 ...if you're wanting to alter the initial behavior.
14:09 jwagner: what are you trying to accomplish?
14:09 jwagner owen, found it -- I'd have to change it in several tmpl files, looks like.
14:09 One of my sites wants it to default to full screen, was just trying to see how that could be done.
14:10 Looks like if I just took out the width=740,height=450 piece of the call, that should do it.
14:24 chris_n owen: why would an onclick even occur as a page loads up?
14:24 owen I don't understand what you're asking
14:25 chris_n sorry
14:26 I have yui menu button which calls a function on an onclick event
14:26 but the function is called as soon as the page loads up rather than when the button is clicked
14:31 owen chris_n: the function would get called as the page loads up if the function isn't defined as a standalone function I guess
14:34 jdavidb I've got a community puzzler for y'all...in member/pay.pl, sub writeoff, the update statement does a longish WHERE on a bunch of different accounttypes.  My question is, do we really *care*?  If the routine is called, we've got the borrowernumber and accountnum, so why select on that?
14:37 owen I guess the question is what do all those accounttypes mean?
14:37 Are those standard codes built into Koha somewhere?
14:37 jdavidb Apparently, yes.  
14:37 owen If I select distinct accounttypes on my system I get NULL, LR, Pay, L, C, CR, F, W, REF, M, A, and FOR
14:38 jdavidb If you ended up with a Pay or W (writeoff), then amountoustanding is already zero, so this wouldn't hurt anything.
14:39 Anything that's a positive-value bill (charging the patron for something), you'd want to be able to write off...anything that's neg-value (payments, writeoffs) are already zero.
14:40 atz fines are screwed up.  that is all.
14:40 pianohacker I think manual credits have a negative amountoutstanding, but that's also easy to ignore
14:40 atz: That is an understatement, is what it is
14:41 jdavidb Well, yes, atz, but I'm trying to figure out whether the fix to my current problem--a manual invoice type that cannot be written off because of this--should be a general Koha patch, or something local.
14:42 atz no idea.  i've sworn off touching fines until it gets overhauled
14:43 Sharon Really? We had no idea you felt that way... ;-)
14:43 jdavidb Unfortunately, I do not have that luxury.
14:44 pianohacker jdavidb: If I understand your problem correctly, the easiest method might be to create a new accounttype and simply modify pay.pl to ignore it
14:44 jdavidb pianohacker: Here's the original remark, from before you came in:
14:45 >I've got a community puzzler for y'all...in member/pay.pl, sub writeoff, the update statement does a longish WHERE on a bunch of different accounttypes. My question is, do we really *care*? If the routine is called, we've got the borrowernumber and accountnum, so why select on that?
14:45 rhcl Is there an echo in here?
14:46 :)
14:46 jdavidb My proposed fix is to chop out the WHERE, rather than adding a bunch of extra ones for new accounttypes.
14:46 atz the types is one of the most "legacy" heavy parts of koha.   it used to be that no one place even contained them all.  
14:46 some types were implicitly counted as negative by one script
14:46 or ignored by another
14:47 jdavidb There are some pretty ugly assumptions all through here, it looks like.
14:48 atz it used to do an update on user-entered text using a LIKE %XX% clause.
14:48 so you could have all kinds of side effects...
14:49 jdavidb Do you know if anyone is already working on an overhaul to this, atz?
14:49 atz ryan was
14:50 not sure what the status is, he's pretty busy
14:50 jdavidb I'm sure.  I know what I'd do with it, if I could go off in the weeds for a couple of weeks and do nothing else, but I don't have *that* luxury, either.
14:51 atz for me the main drag was that I could make it reliable and "correct", but I couldn't handle converting all the bogus legacy data
14:52 jdavidb I had a structure on a napkin that would let you have a cash-drawer reconciliation and everything, just...haven't had time time to hack on it.  
14:53 pianohacker If you throw it up on an RFC, someone else might
14:53 atz the only way to do the "cash drawer" thing right is using browser certificates, imho.  
14:54 that's the only way you know on this side of the internet what machine the user really is on.  IP isn't specific enough.
14:54 jdavidb That's a step farther than I was going to go, atz, but at login time, I was going to have the user select a drawer, and "own" it, and no one else could..kinda a session-cookie-lock thing.  
14:55 There were some hairy bits I hadn't quite worked out, like drawer-ownership, but I knew the general direction I wanted to go on it.
14:55 atz interesting.  
14:56 jdavidb Something *kinda* like Unicorn's named-workstation piece, that made their cash-drawer report possible.  
14:57 It's very tempting to just chop that WHERE out, and see if that breaks anything.
15:04 the only times that sub is called is when you have fines with amountoutstanding >0 on the pay screen, and you select "writeoff" in the pulldown for that fine.  pay.pl loops thru, looking for those, and writing them off one at a time.
15:05 I'll submit it as a Koha patch, and see if gmcharlt throws it back.
15:06 gmcharlt jdavidb: looking forward to it
15:09 jdavidb Thanks, gmcharlt!  Any little thing I can do.. :)
15:12 chris_n owen: you are right; the function is not standalone; so I wrapped the call to it in a conditional and that fixed it up nicely.
15:12 tnx
15:17 kf my "currently available" search option in staff is broken - because the value got translated... http://.../cgi-bin/koha/catalogue/search.​pl?idx=kw&op=and&idx=kw&op=and&idx=kw&lim​it=zur+Verf%C3%BCgung&sort_by=relevance and cant find it in pootle :(
15:17 jdavidb Done deal, gmcharlt.  Even put in a bug report on it....  I may get this process figgered out eventually.
15:17 gmcharlt jdavidb: thanks
15:51 ecorrado does anyone know what this undefined "C4::Members::Messaging::GetMessagingPreference" is supposed to do
15:52 pianohacker There might be more leading up to that error in your error log
15:52 Could you put it on pastebin.com ?
15:54 ecorrado pianohacker: http://pastebin.com/m521b83 is the complete log entry for koha-error.log for today (I only tried it twice :-)
15:56 pianohacker ecorrado: What Koha version are you running?
15:57 ecorrado 3.00.02.012
15:58 pianohacker Is that 3.0.3, or 3.0.2? the about.pl version didn't change between the two
16:02 ecorrado loks like I have 3.0.2
16:02 or at least the tar file I downloaded is koha-3.00.02.tar.gz
16:02 pianohacker k
16:03 ecorrado yea, it looks like 3.0.2 is still the "Latest Stable Release" according to http://koha.org/download/
16:05 gmcharlt indeed
16:05 pianohacker Probably, though 3.0.3 wasn't too major a release
16:11 gmcharlt ecorrado: not sure how it happened, but it seems like you somehow slipped in a HEAD (i.e., future 3.2) version of C4/Circulation.pm into your 3.0.2 install
16:11 pianohacker I wondered how the Circulation Alerts stuff slipped into a 3.0 install
16:12 ecorrado gmcharlt: interesting
16:12 I did try replacing C4/Circulation.pm to fix a bug, so I may have grabbed the wrong one
16:12 pianohacker Ahh
16:15 chris_n can anyone testify to the usability of the results of the current labels csv export functionality?
16:16 atz chris_n: was OK, last i checked... it's the only way to get some UTF-8 stuff out
16:19 chris_n atz: tnx, the question should be regarding the usability of some of my test data... :-(
16:20 ecorrado gmcharlt: moving the old C4_Circulation.pm back seems to work, but of course now I will have bug 2770 back :-(
16:20 munin 04Bug http://bugs.koha.org/cgi-bin/b[…]w_bug.cgi?id=2770 normal, PATCH-Sent, ---, nahuel.angelinetti@biblibre.com, ASSIGNED, Renew a document, set a bad due_date
16:21 Sharon chris_n the only problems we experience with the labels are related to diacritics
16:36 ecorrado gmcharlt++
16:44 pianohacker1 brb, updating in the vain hope that my wireless card will have less than 80% packet loss
16:47 gmcharlt @later tell chris eek - http://torrentfreak.com/movie-[…]3-strikes-090812/
16:47 munin gmcharlt: The operation succeeded.
16:56 owen gmcharlt: How does that work? Will munin tell chris that the next time chris speaks?
16:56 gmcharlt owen: yes, or if he were to drop off and rejoin
16:59 but you see, it's the *past* version of yourself, and thus a perfect target
16:59 rinse and repeat, apply to all :)
17:01 chris_n Sharon: I hope to spend some *more* time looking at that while I'm in the area
17:02 Sharon That would be great.  Our larger libraries rely heavily on the label making tools.
18:03 chris morning
18:04 gmcharlt hi chris
18:05 jdavidb Hi, chris!
18:06 chris yeah, you cant trust the MPAA ... well you can trust them to try and screw everyone (artists included) to make money
18:14 chris_n hi chris
19:03 wizzyrea queryremovestopwords works on both staff and opac?
19:03 are there any bad consequences to turning it on after it having been off?
19:04 (or scripts that need to be run?)
19:23 owen wizzyrea: I think that pref is for NoZebra only

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

koha1