biblibre.com, ASSIGNED, Renew a document, set a bad due_date← 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&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 | 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.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 | 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
