2010-10-06T01:15:12 *** abeNd-org has joined #evergreen 2010-10-06T01:16:18 *** abeNd-org1 has quit IRC 2010-10-06T07:05:13 *** shopkins has joined #evergreen 2010-10-06T08:03:47 *** abeNd-org has quit IRC 2010-10-06T08:52:51 *** Dyrcona has joined #evergreen 2010-10-06T08:56:57 *** gdunbar has quit IRC 2010-10-06T08:58:22 *** gdunbar_ has joined #evergreen 2010-10-06T08:59:47 *** gdunbar has joined #evergreen 2010-10-06T08:59:50 *** gdunbar_ has quit IRC 2010-10-06T09:04:36 *** Meliss has joined #evergreen 2010-10-06T09:10:28 *** phasebb has quit IRC 2010-10-06T09:13:37 *** r123 has joined #evergreen 2010-10-06T09:15:42 *** yboston has joined #evergreen 2010-10-06T09:21:31 *** bshum has joined #evergreen 2010-10-06T09:24:46 eeevil: When it's written that usr_grp in the hold matrix matchpoint is entirely unused currently, does this mean that the latest hold logic is skipping it? Or that nobody seems to be using it at the moment? 2010-10-06T09:25:28 bshum: the logic ignores it 2010-10-06T09:26:47 gmcharlt: Ah, fun times. It's not doing that currently in the 1.6 I'm assuming, because we've written a bunch of rules with that behavior in mind to make use of it when the usr_grp is different than the requestor_grp (like defining the difference between a staff making the request for a patron or a patron making their own request) 2010-10-06T09:27:17 If the logic is ignoring it from now on, I guess we'll have to alter how we write things. 2010-10-06T09:27:33 bshum: yep, there's more work to be done 2010-10-06T09:28:00 gmcharlt: Gotcha, thanks :) 2010-10-06T09:45:04 *** bshum has quit IRC 2010-10-06T09:48:09 eeevil: On the "remove usr_grp from the field order to make it go away" bit, that doesn't do anything but change where it shows up on all of my test installs. 2010-10-06T09:48:17 *** bshum has joined #evergreen 2010-10-06T09:51:24 ah, we need a suppressFields entry 2010-10-06T09:52:13 ahh, indeed, thanks. patch or just fixin' it welcom :) 2010-10-06T09:52:19 * berick fixes 2010-10-06T09:54:43 Side note, anyone take a look at my circ matchpoint stuff since I decided to break backwards compatibility adding things? 2010-10-06T09:55:33 berick: would it be possible to check the value of the circ.holds.usr_not_requestor global flag and put a note on the UI about the behavior? 2010-10-06T09:56:04 tsbere: don't currently have time to consider features w/o migration path :\ 2010-10-06T09:56:06 tsbere: I haven't ... but things are diverging between trunk and 2.0, so now would be the time 2010-10-06T09:56:19 eeevil: indeed it would 2010-10-06T10:01:37 atz__, The latest version of the patch has two pieces of breakage. 1 - Owning/Circ library being set now trumps in all cases (by proximity still though) rather than just in some cases, 2 - Scripts need some adjustment for renewal periods. In DB circ has an upgrade script that fixes the DB changes beyond the weight of the owning/circ lib and names of duration rules. 2010-10-06T10:08:36 Perhaps we need to organize postgresql-like commitfests for handling large patches like this; if we explicitly set aside time on the calendar to review & test large patches, then the patch submitters will have a better idea of when to expect feedback / focus on their work 2010-10-06T10:08:42 tsbere: Can you describe a bit more of what that first problem means? "trumps in all cases" (for those of us spectators out there) 2010-10-06T10:09:29 * dbs doesn't want people like tsbere to go away frustrated 2010-10-06T10:09:48 bshum: Previously a really close match on owning or circ library would trump renewal flag in ordering, but a less close match would be trumped by renewal flag. I changed it so that regardless of how close the match is, if it is set it should trump renewal flag in ordering. 2010-10-06T10:11:34 Scheduled patch-review sessions like that might make it easier for EG libraries to feel like they have a better understanding of the development process for contributions; easier to set expectations in terms of times and more clarity in process / communication 2010-10-06T10:11:39 * dbs digs back into his own code 2010-10-06T10:12:18 dbs: It isn't frustrated. It is more of a "I prefer to limit my active code changes on any given project so as to not spread my attention too thin when feedback comes in" thing. Not that scheduled review sessions sounds like a bad idea. 2010-10-06T10:12:39 * dbs is glad tsbere isn't frustrated 2010-10-06T10:14:14 bshum: That enough of an elaboration for you, or would you like a better description? 2010-10-06T10:15:16 tsbere: I think that makes sense to me. I'll admit I haven't followed these changes as closely as I should have, but overall they look pretty nice to me. I especially like how the renewal portion is being moved out of the duration piece. Even if that does break scripts, it'll make life alot easier to explain as we set things up... 2010-10-06T10:16:15 bshum: Well, that part is assuming that it gets approved. Tis a bit more controversial than the fallthrough portion. 2010-10-06T10:16:49 tsbere: True, I've had that as a wishlist on our end for a bit though, so it's nice to see it being considered as part of the changes. 2010-10-06T10:19:32 tsbere: For our consortium, we share the same durations, but have different renewals at each site. Not impossibly complicated, but it'd be easier to manage our circ rules if the renewal was a separate piece. 2010-10-06T10:20:47 *** StephenGWills has joined #evergreen 2010-10-06T10:20:53 bshum: My main concern was that fallthrough is a lot easier to deal with when you don't have what I would call unreleated data points forcibly tied together. Which would likely help your consortium, set the duration at the top and then the renewals at the system or branch levels. 2010-10-06T10:21:30 tsbere: You know, I haven't thought of it that way, but that would make life immensely simpler. 2010-10-06T10:21:55 tsbere: I think in our consortium, it would mainly differ in renewals and fine rates. 2010-10-06T10:22:10 tsbere: But with fallthrough, it would work much simpler from the get-go 2010-10-06T10:22:26 bshum: That was the idea. 2010-10-06T10:22:40 * bshum cheers 2010-10-06T10:24:18 tsbere: Side question, unrelated, but afterl and Meliss were wondering if you (or anyone else) had an opportunity to poke at the staff client's button bar to have it launch a new tab whenever you click on them instead of merely replacing the existing active tab content. 2010-10-06T10:25:30 bshum: I was waiting on more stuff like that until my tabbing/cli stuff was pushed into trunk. That just happened, so I may get to that soon (see comment above about too many changes active at once) 2010-10-06T10:25:52 tsbere: Heh, fair enough. Super excited about the tab changes too. 2010-10-06T10:28:42 bshum: if you have a trunk server, it's worth testing those things more 2010-10-06T10:28:58 phasefx: Yep, that's what I'm installing right now actually :) 2010-10-06T10:29:20 putting the NSIS installer through it's paces on different versions of Windows would rock too 2010-10-06T10:29:26 s/it's/its/ 2010-10-06T10:30:06 phasefx: I could grab a lab laptop or something to give that some attempts. I don't have Windows at my desk anymore. 2010-10-06T10:30:38 Erm, remind me where those installers are again? 2010-10-06T10:30:47 phasefx: I have tested it on XP, Vista x32, Vista x64, and 7 x64 so far personally. 2010-10-06T10:31:07 tsbere++ 2010-10-06T10:31:28 there's also admin accounts versus regular users to consider 2010-10-06T10:32:13 bshum: the staff client makefile can make use of an optional dependency, a program called NSIS, and cross-compile windows installers from a unix environment 2010-10-06T10:32:14 Beyond XP, I ran the installer as a normal user on all of the above. It prompts for an admin account in all non-XP cases. 2010-10-06T10:33:08 bshum: we also have better support for using the staff client as a firefox extension 2010-10-06T10:33:15 phasefx: Interesting. That's a new feature in the trunk install right? 2010-10-06T10:33:27 bshum: earlier patch from tsbere 2010-10-06T10:33:34 in trunk, yes 2010-10-06T10:34:57 Cool. I'll see what I discover as I attempt to install it today. Thanks guys! 2010-10-06T10:39:03 bshum: http://evergreen-ils.org/dokuwiki/doku.php?id=mozilla-devel:building_the_staff_client 2010-10-06T10:46:01 *** kmlussier has joined #evergreen 2010-10-06T10:50:44 *** dchristens has joined #evergreen 2010-10-06T10:51:54 more Acq notes: searching for selection lists, using the "IS NOT" operator seems to always return empty set. 2010-10-06T10:53:40 id != -1, for example 2010-10-06T10:55:58 atz__: a quick test did not result in anything weird for me (selection list id is NOT -1) 2010-10-06T10:56:01 but 2010-10-06T10:56:05 maybe try the refresh grid button? 2010-10-06T10:56:07 atz__: <> or 'is not' => undef 2010-10-06T10:56:40 Is there a canonical way of deleting all of an org_unit's copies/call_numbers/bibs? There's only about 2500 bibs; we've re-processed their source recs. 2010-10-06T10:57:26 *** afterl has joined #evergreen 2010-10-06T10:57:58 senator: no, i just get the popup that says "no results" 2010-10-06T10:58:50 if i reload, i get the same thing (though it takes 3 times as long) 2010-10-06T10:59:05 hrm 2010-10-06T10:59:15 for example, just go to "My Selection Lists" 2010-10-06T10:59:24 reveal search form 2010-10-06T10:59:42 change owner IS to: 2010-10-06T10:59:54 owner IS NOT 'whomever' 2010-10-06T11:00:13 aha 2010-10-06T11:00:27 ok that's specific to actor.usr fields, but indeed that is a bug 2010-10-06T11:00:41 dchristens: hmm. nothing canonical I know of; maybe something like "DELETE FROM biblio.record_entry WHERE id IN (SELECT record FROM asset.call_number WHERE owning_lib = ) CASCADE" but if any circs have happened on those copies that might be bad 2010-10-06T11:01:31 dbs: no circs yet, so that should be ok. Thanks :-) 2010-10-06T11:01:57 Oh, and the DELETE rule would just turn that into setting "deleted = TRUE" on biblio.record_entry, so that might not do exactly what you want anyway 2010-10-06T11:02:33 hmm. drop the rule, do the DELETE CASCADE thing, and re-create the rule? 2010-10-06T11:02:35 * dbs has never tried that out and doesn't trust his cold-medication-addled-head 2010-10-06T11:02:51 dbs: 2010-10-06T11:02:58 dchristens: you could try that. I would recommend trying it on a test database first :) 2010-10-06T11:03:54 dchristens: any reason you don't want to just update the biblio.record_entry.marc with the reprocessed MARC records and reingest those 2500? 2010-10-06T11:05:04 dbs: my first cut (on test box) was to drop the protect rules on copy and call_number, toast those recs and re-create the rules, and then delete the metabib and biblio.record_entry recs... but I wasn't sure if that would get me in trouble on the prod server 2010-10-06T11:05:28 *** youdonotexist has joined #evergreen 2010-10-06T11:05:58 dbs: updating biblio.record_entry.marc - huh.... never thought of that :-) 2010-10-06T11:06:35 dchristens: I'm not saying I've ever had to update 100K MARC records due to corrupted diacritics and reingest them... heh 2010-10-06T11:06:44 err, wait... yes I am 2010-10-06T11:06:52 :-D 2010-10-06T11:07:17 eeevil: I wonder if r18151 is going to be backported to rel_2_0? I see it was backported to rel_1_6. 2010-10-06T11:07:38 what's the process for reingesting? 2010-10-06T11:08:09 dchristens: http://evergreen-ils.org/dokuwiki/doku.php?id=scratchpad:random_magic_spells#reingesting_bib_records 2010-10-06T11:08:15 dchristens: you going to be at Access? 2010-10-06T11:08:20 dbs++ 2010-10-06T11:08:32 dbs: yep - just got approval last week :-) 2010-10-06T11:08:40 woohoo 2010-10-06T11:08:48 dbs: buy you a beer? 2010-10-06T11:10:07 dchristens: after Hackfest and my session are over, I'm going to need a beer. Or ten :) 2010-10-06T11:10:13 :-) 2010-10-06T11:16:35 Excellent - that looks like it should work :-) I'm off to tinker with it - thanks again! 2010-10-06T11:20:52 *** moodaepo has joined #evergreen 2010-10-06T11:22:15 Add Brief Record page needs to block submission if picklist combobox is empty 2010-10-06T11:23:05 Otherwise the client only gives an opaque "Could not connect to DB" error 2010-10-06T11:30:31 *** mrpeters-isl has quit IRC 2010-10-06T11:36:00 phasefx: "Check in" from "Items Out" page for an item with a hold placed on it results in "TypeError: req is undefined" alert, then "Could not load 'fieldmapper.AutoIDL' alert when I dismiss that - alpha4. seen that? 2010-10-06T11:36:49 * phasefx has not seen that, will queue it up for look'n 2010-10-06T11:37:34 JS Console also has "TypeError: obj.bill_window is undefined" 2010-10-06T11:38:05 dbs: something else I noticed recently, errors in summary.js/display.js if you batch retrieve patrons from patron search 2010-10-06T11:40:45 *** _bott_ has left #evergreen 2010-10-06T11:41:46 Dibs on 0432 for an upgrade script 2010-10-06T11:42:16 dear george: i have something that will probably do what you want, but i can't share it yet. sorry, jeff. :P 2010-10-06T11:42:20 *headdesk* 2010-10-06T11:44:42 *** mrpeters-isl has joined #evergreen 2010-10-06T11:45:41 *** _bott_ has joined #evergreen 2010-10-06T11:49:41 jeff: at the record level, there is of course already the ability to generate separate feeds for new / modified records beginning from an arbitrary date 2010-10-06T11:50:25 So for George's purpose, it sounds like only the deleted axis is missing (if memory serves). 2010-10-06T11:50:43 but I know jeff has cool item-level feeds that the whole Evergreen world would appreciate 2010-10-06T11:50:47 yes. i have a bib enumerator for doing paged record harvests for holdings at a library based on (iirc) all the needed variables. 2010-10-06T11:50:54 *** atz has joined #evergreen 2010-10-06T11:51:02 "bibs for libs", as it were 2010-10-06T11:51:13 sorry, venting my frustration here serves no useful purpose. :) 2010-10-06T11:51:16 *** atz__ has quit IRC 2010-10-06T11:54:04 berick++ # my feeble eyes appreciate it 2010-10-06T11:54:59 *** atz has quit IRC 2010-10-06T11:55:18 *** brian_f has joined #evergreen 2010-10-06T11:55:47 *** atz has joined #evergreen 2010-10-06T11:55:49 dbs: heh, mine too 2010-10-06T12:02:14 berick: thanks from me too 2010-10-06T12:06:25 hrm. "opac visible" patron stat cats... do they actually show anywhere in my account in a 1.6 opac? 2010-10-06T12:06:38 i'm not seeing them, but i may not be looking in the right place. 2010-10-06T12:06:39 eeevil: sure thing 2010-10-06T12:14:16 jeff: I see {"__c":"actscecm","__p":[1,2,"English",15429]} in open-ils.actor.user.fleshed.retrieve call, but it's not exposed anywhere in the HTML 2010-10-06T12:14:55 dbs: thanks! 2010-10-06T12:15:42 And I think you'd need to add one more call to actually retrieve the name of each patron stat cat 2010-10-06T12:16:06 * dbs checks to see if our "language preference" stat cat actually is set to be opac visible 2010-10-06T12:16:58 Oh, that's goood 2010-10-06T12:17:21 Our "preferred language" stat cat opac_visible column = 'f'. 2010-10-06T12:17:33 and i can see some libs wanting to have opac visible stat cats that users can change, and others that they cannot. 2010-10-06T12:18:36 then there's the free-form vs from-a-list... oof. not thinking about it right now, moving on. 2010-10-06T12:19:17 patrons can turn phone pre-overdues on/off with staff, next steps will be giving them the ability to change that in the opac. 2010-10-06T12:19:44 most of those opting in to pre-overdue phone calls will not log in to the opac anyway. 2010-10-06T12:35:26 Anybody else finding these in their apache logs: 2010-10-06T12:35:28 [Wed Oct 06 16:56:26 2010] [info] SSL Library Error: 336027900 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol speaking not SSL to HTTPS port!? 2010-10-06T12:35:29 ? 2010-10-06T12:35:47 atz: yep, lots of it 2010-10-06T12:36:02 yeah, i have a ton just on my single user dev system 2010-10-06T12:36:17 atz: I see that a lot, on all my servers that run HTTPS, evergreen or no. 2010-10-06T12:36:22 i imagine on a live production system it would be tons 2010-10-06T12:37:06 is that from an XHR or xulrunner bug? or something else? 2010-10-06T12:37:50 *** jamesrf has joined #evergreen 2010-10-06T12:39:17 atz: Some browsers seem to poke HTTPS ports without SSL first. Xulrunner and firefox may do that. I also see bots scanning for things pretending to be HTTPS by port when they aren't actually using SSL. 2010-10-06T12:39:26 ah, nice alphag seems to get it fixed: http://www.mail-archive.com/open-ils-dev@list.georgialibraries.org/msg03019.html 2010-10-06T12:39:43 http://www.mail-archive.com/openssl-users@openssl.org/msg50214.html 2010-10-06T12:41:00 I get those a lot even with that kind of tweaking. <_< 2010-10-06T12:41:54 atz: you need to change the order of your Listen statements, and that should resolve it. See my notes here: http://wiki.apache.org/httpd/InternalDummyConnection 2010-10-06T12:42:14 specifically: > You can work around this by ensuring that the last Listen directive in your server configuration is not using SSL. In a typical setup, this would mean that "Listen 443" would come before "Listen 80". 2010-10-06T12:42:19 yep, found your email to that effect 2010-10-06T12:42:21 * dbs was trying to find jeff's fix 2010-10-06T12:42:24 thx jeff 2010-10-06T12:42:29 'welcome! 2010-10-06T12:42:57 I thought we had fixed that config order in the default apache setup ages ago 2010-10-06T12:43:10 i thought so also. 2010-10-06T12:43:29 (note: our production server does not generate those error messages - I was referring to my Squeeze vm) 2010-10-06T12:43:45 might depend on the OS distro's apache setup 2010-10-06T12:43:49 right 2010-10-06T12:43:50 some have a ports.conf file, some don't 2010-10-06T12:44:12 the install docs can probably benefit from a reference to it 2010-10-06T12:45:19 is there any legit reason apache would probe itself though? i get the fix, but i guess i don't get behavior. 2010-10-06T12:45:55 it has to do with how apache internally handles the setup/teardown of children/workers/threads 2010-10-06T12:46:00 (depending on your MPM) 2010-10-06T12:46:32 i've no idea why that method was chosen, vs some other form of signals/IPC 2010-10-06T12:46:35 but it only affects the last port in the mix? seems screwy 2010-10-06T12:46:45 right, I think we've flipped between "just comment out the Listen 443 directive in eg_vhost.conf" vs "comment it out in ports.conf"; the latter is more invasive, but leaving it in ports.conf causes the ordering problem, apparently 2010-10-06T12:47:56 atz: well, each child binds to all configured ports, so you only have to hit one, and it hits the last mentioned. 2010-10-06T12:48:34 ah, ok, that makes *some* sense 2010-10-06T12:49:09 if it got to the last one, then it got *through* all the rest of the configs to that point 2010-10-06T12:49:12 atz: unreleased (or maybe now released-but-not-packaged) apache httpd now goes with the last non-HTTPS port -- and i don't recall what it does when there are no non-SSL ports. :) 2010-10-06T12:49:49 heh 2010-10-06T12:50:18 jeff: I seem to recall some chatter in another place about "no non-SSL ports? make a local dummy one that only takes local traffic to talk to" type stuff 2010-10-06T12:51:16 atz: and upon further reflection, i suspect that the reason they went with this method is an inability to reliably/portably predict which child will get the connect of all that are listening. 2010-10-06T13:02:47 that makes sense too 2010-10-06T13:06:44 hmm... multiple cable trucks pulling up to the optical tap in the alley... we'll see if they affect my conx 2010-10-06T13:31:23 *** tildeequals has quit IRC 2010-10-06T13:40:01 *** tildeequals has joined #evergreen 2010-10-06T13:49:44 *** artunit has quit IRC 2010-10-06T13:51:13 *** kmlussier has quit IRC 2010-10-06T13:52:00 *** mck9 has left #evergreen 2010-10-06T13:52:17 *** mck9 has joined #evergreen 2010-10-06T13:58:24 *** atz_ has joined #evergreen 2010-10-06T14:00:19 *** atz has quit IRC 2010-10-06T14:00:46 *** youdonotexist has quit IRC 2010-10-06T14:01:17 *** youdonotexist has joined #evergreen 2010-10-06T14:02:44 *** kmlussier has joined #evergreen 2010-10-06T14:03:40 *** afterl1 has joined #evergreen 2010-10-06T14:04:50 *** afterl has quit IRC 2010-10-06T14:15:59 Question: Would my circ matchpoint stuff, potentially controversial changes and all, be more likely to be accepted if I write a pile of "this is how indb circ works after that patch" docs? 2010-10-06T14:19:08 tsbere: I like the docs just for notes. Plus I imagine that the documentation group would enjoy that. 2010-10-06T14:19:09 tsbere: that would certainly help, but would also help is a clear migration path for the libraries who are already using in-DB circ now 2010-10-06T14:23:05 *** kmlussier has quit IRC 2010-10-06T14:29:33 gmcharlt: That does sound like a good thing. After I send out 11.5 thousand emails and unpack 7 more servers I may start on that. 2010-10-06T14:31:05 *** brian_f has left #evergreen 2010-10-06T14:34:07 *** jenny has joined #evergreen 2010-10-06T14:34:12 is there an 0429 lingering out there that someone didn't checkin? 2010-10-06T14:34:17 *** jenny has left #evergreen 2010-10-06T14:37:52 Does anyone know if Evergreen can support OAI harvesting? 2010-10-06T14:37:54 tsbere, I'll give you a extra cheese puff for a "this is how indb circ works" doco. :) 2010-10-06T14:38:12 StephenGWills: Currently works, or after my patch works? They vary. 2010-10-06T14:38:18 LOL! 2010-10-06T14:38:26 see? I always get that answer :) 2010-10-06T14:38:34 StephenGWillis: I'll take the cheese puff if you can accept dcc. 2010-10-06T14:39:02 * StephenGWills starts cramming cheese puffs into a spare USB port 2010-10-06T14:39:14 I've got how it currently works in a document. 2010-10-06T14:40:19 With some notes specific to our migration at the end. If you can do dcc I can send it to you over IRC. 2010-10-06T14:40:22 *** pmplett has joined #evergreen 2010-10-06T14:41:35 Also, would you prefer OpenDocument Format or Word. 2010-10-06T14:41:58 I assume that I can. I'm an open office guy. 2010-10-06T14:42:18 You mean LibreOffice don't you? /smirk 2010-10-06T14:42:37 I'm still using OO.o though I did download LibreOffice. 2010-10-06T14:42:51 Looks like it is mostly Novell's Go-OO right now. 2010-10-06T14:42:58 Haha 2010-10-06T14:43:10 * StephenGWills stops cramming cheese snacking into his usb port and heads to google for enlightenment 2010-10-06T14:44:00 Hmm... Looks like I can't send it through IRC at the moment. It's greyed out.... 2010-10-06T14:44:37 tsbere can probably send it, though. 2010-10-06T14:44:47 He's using a "real" IRC client. 2010-10-06T14:45:54 * tsbere offers files and hopes they work 2010-10-06T14:45:57 * Dyrcona is apparently using a "fake" IRC client. :) 2010-10-06T14:45:59 Fancy 2010-10-06T14:47:31 * tsbere thinks the firewalls in the middle are a problem 2010-10-06T14:48:41 nod 2010-10-06T14:49:18 *** youdonotexist has quit IRC 2010-10-06T14:50:25 sorry, my cats smelled the cheeseballs and started swarming 2010-10-06T14:53:54 I know it's low tech but email works too. 2010-10-06T14:55:00 can send to swills@beyond-print.com and avoid the spam filters responsible IT departments use. 2010-10-06T14:55:46 "responsible" IT eh? 2010-10-06T14:56:06 Right.... 2010-10-06T14:56:23 did I misspell that again? 2010-10-06T15:00:57 Dyrcona++ may I post that on the wiki for you? 2010-10-06T15:04:53 StephenGWills: I may end up writing an actual wiki-ized version that covers the current, post my patch, and converting between them 2010-10-06T15:10:34 any reason why a given doc shouldn't just be posted to the list (assuming CC-BY-SA license)? would be nice for the DIG I think 2010-10-06T15:11:11 I mean, by all means wiki-ize and extend with your extra info, tsbere - that would be cool too 2010-10-06T15:11:53 the wiki has language now too that states that edits should be CC-BY-SA 2010-10-06T15:12:15 DIG wrangled that long ago 2010-10-06T15:12:21 crap, my attempt to send this out crashed. I threw too much at it. 2010-10-06T15:12:32 * tsbere has to figure out what ones did go through now. :( 2010-10-06T15:21:31 *** brian_f has joined #evergreen 2010-10-06T15:26:45 StephenGWills: Yes, but delete the last part that's specific to our consortium and our current ILS. 2010-10-06T15:27:11 I've been meaning to put it on the wiki, but haven't made myself actually do it. 2010-10-06T15:30:09 bshum: I'll email you a copy, too. I have your email address already. 2010-10-06T15:31:39 Dyrcona: Thanks! Appreciate your insights as always. 2010-10-06T15:35:21 StephenGWills: Special note to you as a reminder, Dyrcona's doc is designed using trunk I assume, not 1.6 2010-10-06T15:35:42 So some of the fields won't match up to what you'll see in a "live" system right away. 2010-10-06T15:46:14 *** kmlussier has joined #evergreen 2010-10-06T15:50:24 *** brian_f has quit IRC 2010-10-06T15:59:15 *** Meliss has quit IRC 2010-10-06T16:00:46 *** jamesrf has quit IRC 2010-10-06T16:09:56 *** shopkins has quit IRC 2010-10-06T16:24:43 *** bshum has quit IRC 2010-10-06T16:26:30 *** brian_f has joined #evergreen 2010-10-06T16:31:30 *** jamesrf has joined #evergreen 2010-10-06T16:46:18 *** kmlussier has quit IRC 2010-10-06T16:59:03 *** r123 has quit IRC 2010-10-06T17:00:34 *** afterl1 has quit IRC 2010-10-06T17:13:22 *** dchristens has quit IRC 2010-10-06T17:20:29 *** LBA has joined #evergreen 2010-10-06T17:31:20 *** Dyrcona has quit IRC 2010-10-06T17:48:22 *** yboston has quit IRC 2010-10-06T18:34:58 *** pmplett has quit IRC 2010-10-06T18:41:19 ok, so I have a TT2 problem 2010-10-06T18:41:26 Error processing Trigger template: file error - parse error - input text line 66-67: unexpected token (ftx_vals) 2010-10-06T18:41:47 the line in question is: [% If ftx_vals.size == 0; ftx_vals.unshift('.'); END; # BT needs FTX+LIN for every LI, even if it's an empty one %] 2010-10-06T18:42:25 so that is insane is that ftx_vals is declared and operated on in preceding lines 2010-10-06T18:42:31 *what 2010-10-06T18:42:55 where's the beef? 2010-10-06T18:49:45 does if need () or a then? 2010-10-06T18:54:55 * tsbere has now looked, doesn't appear to 2010-10-06T18:55:09 atz_: Every if I see is IF, not If. Could that be the problem? 2010-10-06T18:55:17 i always use IF 2010-10-06T18:55:26 hmmm... might be it. 2010-10-06T18:55:29 testing 2010-10-06T18:55:54 is it your second ftx_vals.unshift('.')? 2010-10-06T18:56:03 right 2010-10-06T18:56:19 awfully insidious if that is it 2010-10-06T18:56:31 continuing syntax error from lines previous seems unlikely due to the [% %] style of tt2 2010-10-06T18:56:56 yeah, i had a bunch of directives in a big [% block %] 2010-10-06T18:57:09 but i broke them out to get tighter error reporting in debugging this 2010-10-06T18:58:30 wow, that was it 2010-10-06T18:59:13 needed IF instead of If? 2010-10-06T18:59:20 yeah 2010-10-06T18:59:34 but "ftx_vals" is the unexpected token. LAME 2010-10-06T19:00:01 No, that makes sense 2010-10-06T19:00:17 it can make sense and still be lame. :) 2010-10-06T19:00:49 If became a "we dunno" variable. ftx_vals wasn't something that could deal with said variable. The lame part is that the command IF has to be IF, not if, If, or iF. :P 2010-10-06T19:00:55 it makes sense that the parser *knows* something is off at that point, bc "If" might be the start of a declaration 2010-10-06T19:01:16 but it is entirely lame to only *report* the 2nd token 2010-10-06T19:01:26 *** phasebb has joined #evergreen 2010-10-06T19:02:00 I think what I had to do was lame 2010-10-06T19:02:20 Sending out 11k+ emails for "would you like to join the library's mailing list?" <_< 2010-10-06T19:02:44 hah... hopefully you got to put your director's email as the reply-to 2010-10-06T19:02:47 there's an ANYCASE option for tt2, but i wouldn't enable it for general use. 2010-10-06T19:03:07 tsbere: ouch. 2010-10-06T19:03:26 anyway, reference under Implicit Directives, http://template-toolkit.org/docs/manual/Syntax.html 2010-10-06T19:03:56 atz_: Wasn't my director. I don't work for a library directly. Still, yea, they are the list owner and get the complaints. :D 2010-10-06T19:04:55 and yet some stuff is case insensitive. odd. http://template-toolkit.org/docs/manual/Directives.html#section_USE 2010-10-06T19:05:19 tsbere: whose netblock? who gets the abuse reports? :) 2010-10-06T19:05:50 ok, I technically get those or a copy of those. <_< 2010-10-06T19:06:16 *** phasebb has quit IRC 2010-10-06T19:06:31 But we send out thousands of notices a week anyway..... 2010-10-06T19:11:48 jeff++ # thx for the proofread 2010-10-06T19:12:02 tsbere++ 2010-10-06T19:19:08 *** phasebb has joined #evergreen 2010-10-06T19:26:13 *** pmplett has joined #evergreen 2010-10-06T19:38:40 So, I have figured out what I need to do for "open in a new tab instead of the current tab" thing for the toolbar......should I make it happen for menu items when you hold ctrl? 2010-10-06T19:39:07 makes sense to me 2010-10-06T19:39:21 No, wait, some of them would say "you were holding ctrl" because that is their hotkey....hmmm..... 2010-10-06T19:51:08 what do you mean by "for the toolbar"? 2010-10-06T19:51:31 surely you can detect a ctrl+click vs a ctrl+key 2010-10-06T19:52:54 i'd hope so. 2010-10-06T19:55:27 oh. s/toolbar/"button bar"/ 2010-10-06T19:55:42 or is this for a new more-toolbar-like-buttonbar? 2010-10-06T19:59:29 jeff: I was thinking "the menu gets similar treatment" but I don't know if I can detect ctrl on a click compared to accesskey yet. 2010-10-06T19:59:51 I should be able to detect "click on toolbar/buttonbar compared to menu" easily enough, though. 2010-10-06T20:54:17 *** brian_f has left #evergreen 2010-10-06T22:30:43 *** atz_ has quit IRC 2010-10-06T22:31:03 *** atz__ has joined #evergreen 2010-10-06T22:36:35 *** atz_ has joined #evergreen 2010-10-06T22:39:30 *** atz__ has quit IRC 2010-10-06T22:51:44 *** LBA has quit IRC 2010-10-06T22:54:56 *** LBA1 has joined #evergreen 2010-10-06T23:03:28 *** jamesrf has quit IRC 2010-10-06T23:05:50 *** artunit has joined #evergreen 2010-10-06T23:29:23 *** finnapz has quit IRC 2010-10-06T23:43:13 *** finnapz has joined #evergreen