Time |
S |
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 |
|
jwagner |
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 |
|
gmcharlt |
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 |
|
gmcharlt |
*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 |
|
chris_n |
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 |
|
owen |
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 |
|
hdl_laptop |
Already up on koha_biblibre |
13:21 |
|
hdl_laptop |
but maybe you want to test. |
13:21 |
|
gmcharlt |
hdl_laptop: picking from the branch is fine |
13:22 |
|
gmcharlt |
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 |
|
hdl_laptop |
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 |
|
gmcharlt |
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 |
|
hdl_laptop |
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 |
|
gmcharlt |
but doing a further commits that updates the current set of udpatedatabase entries for new_acq |
13:25 |
|
gmcharlt |
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 |
|
hdl_laptop |
This one has three folowups |
13:31 |
|
gmcharlt |
jumping from 3.0.3 to 3.1.0.110 - odd |
13:31 |
|
gmcharlt |
but anyway, it does look like the new_acq updates |
13:32 |
|
gmcharlt |
have been consolidated, so thanks |
13:32 |
|
gmcharlt |
doe |
13:32 |
|
gmcharlt |
does |
13:32 |
|
gmcharlt |
2614 # SORRY , NO AQBUDGET/AQBOOKFUND -> AQBUDGETS IMPORT JUST YET, |
13:32 |
|
gmcharlt |
2615 # BUT A NEW CLEAN AQBUDGETS TABLE CREATE FOR NOW.. |
13:32 |
|
gmcharlt |
still apply? |
13:32 |
|
gmcharlt |
or is that handled by the followups? |
13:36 |
|
hdl_laptop |
not handled |
13:36 |
|
hdl_laptop |
sorry. |
13:36 |
|
hdl_laptop |
It is handled. |
13:36 |
|
hdl_laptop |
The comments are vetigual |
13:37 |
|
hdl_laptop |
vestigual |
13:37 |
|
hdl_laptop |
even |
13:40 |
|
owen |
What is the purpose of the z39.50 search button on the staff client detail page? |
13:41 |
|
owen |
Can someone explain what workflow that fits into? |
13:49 |
|
owen |
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 |
|
wizzyrea |
:) |
14:02 |
|
wizzyrea |
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 |
|
owen |
collum: Unfortunately no. |
14:08 |
|
owen |
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 |
|
collum |
-- 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 |
|
owen |
...if you're wanting to alter the initial behavior. |
14:09 |
|
owen |
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 |
|
jwagner |
One of my sites wants it to default to full screen, was just trying to see how that could be done. |
14:10 |
|
jwagner |
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 |
|
chris_n |
I have yui menu button which calls a function on an onclick event |
14:26 |
|
chris_n |
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 |
|
owen |
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 |
|
jdavidb |
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 |
|
pianohacker |
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 |
|
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:45 |
|
rhcl |
Is there an echo in here? |
14:46 |
|
rhcl |
:) |
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 |
|
atz |
some types were implicitly counted as negative by one script |
14:46 |
|
atz |
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 |
|
atz |
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 |
|
atz |
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 |
|
atz |
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 |
|
jdavidb |
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 |
|
jdavidb |
It's very tempting to just chop that WHERE out, and see if that breaks anything. |
15:04 |
|
jdavidb |
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 |
|
jdavidb |
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 |
|
chris_n |
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&limit=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 |
|
pianohacker |
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 |
|
ecorrado |
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 |
|
ecorrado |
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 |
Bug http://bugs.koha.org/cgi-bin/b[…]w_bug.cgi?id=2770 normal, PATCH-Sent, ---, nahuel.angelinettibiblibre.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 |
|
gmcharlt |
but you see, it's the *past* version of yourself, and thus a perfect target |
16:59 |
|
gmcharlt |
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 |
|
wizzyrea |
are there any bad consequences to turning it on after it having been off? |
19:04 |
|
wizzyrea |
(or scripts that need to be run?) |
19:23 |
|
owen |
wizzyrea: I think that pref is for NoZebra only |