| # | Time | Nick | Message |
|---|
| # | 07:46:01 | collum has joined #evergreen |
| # | 08:29:02 | Dyrcona has joined #evergreen |
| # | 08:35:14 | Shae has joined #evergreen |
| # | 08:36:30 | mrpeters-isl_ has joined #evergreen |
| # | 08:42:18 | mrpeters-isl_ has quit IRC |
| # | 08:51:10 | akilsdonk has joined #evergreen |
| # | 08:59:07 | csharp | errors while doing post install reingest: http://pastebin.com/2PYCj0dR |
| # | 09:00:42 | csharp assumes for the moment that the problem is "marc" rather than "marcxml" as in //marc:datafield[@tag='020']/marc:subfield[@code='a' or @code='z'] |
| # | 09:00:49 | gmcharlt | csharp: for your cmf entries that use the the marcxml format, only one of 'marc:' or 'marcxml:' is correct |
| # | 09:01:23 | gmcharlt | so yeah, get them in sync with the prefix expected in config.xml_transform, then it should start working |
| # | 09:01:37 | csharp | gmcharlt: okay - makes sense |
| # | 09:09:13 | bwicksall has joined #evergreen |
| # | 09:09:39 | _bott_ has quit IRC |
| # | 09:10:04 | _bott_ has joined #evergreen |
| # | 09:38:10 | jenny has joined #evergreen |
| # | 09:48:00 | akilsdonk has quit IRC |
| # | 09:51:30 | mrpeters-isl | anyone done a presentation recently on new features in 2.1? especially, for the public user... |
| # | 09:54:15 | tsbere can guarantee that he hasn't.....hard to do a presentation on "new features in 2.1" when you all but migrated into post-2.1 |
| # | 09:57:36 | mrpeters-isl | :) |
| # | 09:57:52 | mrpeters-isl | trying to comb through release notes for things that a patron would actually care about |
| # | 09:58:38 | bshum | -= THIS MESSAGE NOT LOGGED =- |
| # | 09:58:57 | bshum | amusingly/unfortunately? |
| # | 09:59:26 | Dyrcona | Yes, definitely more flashy patron stuff in 2.2. |
| # | 10:00:07 | bshum | The 2.1 felt more administrative different (with the revised circ matrix stuff) and staff different (unified vol/copy editor) |
| # | 10:01:38 | bshum | At least those were the "big" things I remember off the top of my head. |
| # | 10:01:40 | csharp | mrpeters-isl: I did a summary presentation yesterday (like 5 mins) for our libraries |
| # | 10:02:01 | bshum supposes it's a "bigger" leap for csharp ;) |
| # | 10:02:07 | csharp | it is ;-) |
| # | 10:02:29 | bshum | Most OPAC side stuff didn't really change from 2.0 to 2.1, so patrons? Hmm |
| # | 10:03:05 | bshum | The cache stuff is so nice, but nobody outside of the poor admins really care about that, right? |
| # | 10:03:27 | csharp | bshum: oh - I think that's a huge advantage for everyone |
| # | 10:03:53 | csharp had to instruct the patrons of the state of Georgia about how to clear a browser cache |
| # | 10:04:05 | bshum | Indeed :S |
| # | 10:04:18 | tsbere | Backend improvements are good, even for those who don't see them directly. |
| # | 10:04:43 | csharp | yeah - anything that improves speed or findability will be welcome |
| # | 10:04:56 | mrpeters-isl | csharp: could i check it out? |
| # | 10:05:00 | mrpeters-isl | http://evergreen.lib.in.us/newfeatures21.html is boring :( |
| # | 10:05:12 | akilsdonk has joined #evergreen |
| # | 10:05:54 | tsbere | mrpeters-isl: Not only boring, but redundant! |
| # | 10:05:58 | bshum | Multi-part hold placement is there twice |
| # | 10:06:04 | csharp | mrpeters-isl: I basically read from a list: http://pastebin.com/A9JS61kX |
| # | 10:06:08 | bshum | But maybe that's intended? |
| # | 10:06:55 | csharp | remember that "new" means "new from 1.6.1" in our case ;-) |
| # | 10:07:04 | mrpeters-isl | oops |
| # | 11:05:04 | jeff | more of a generic postgres question, but i'll ask here first because folk are familiar with the schema... |
| # | 11:05:39 | jeff | i want to select one row per patron with one of the fields containing every valid post_code associated with the patron. |
| # | 11:06:06 | bshum | Fun times. |
| # | 11:06:50 | bshum | Vaguely reminds me of something I might have written for circ rules viewing to include looped in max circ mod limits and having the names of the various circ mods next to the single matchpoint. |
| # | 11:07:01 | jeff | I'm thinking array_accum (now array_agg?) and a subquery |
| # | 11:07:46 | mrpeters-isl | anyone experimented with using awstats to analyze Evergreen traffic? |
| # | 11:08:08 | mrpeters-isl | http://apple.evergreen.lib.in.us/cgi-bin/awstats-7.0/wwwroot/cgi-bin/awstats.pl?config=Evergreen -- for example |
| # | 11:08:27 | bshum | jeff: I think I did something like array_to_string(array_agg(field_I_want), ', ') to insert the values as comma separated. |
| # | 11:08:49 | bshum | in the select portion of the SQL |
| # | 11:09:36 | bshum | mrpeters-isl: That sounds very interesting. We've been meaning to put more efforts into tracking usage too. Right now we're using Piwik to collect general usage information. |
| # | 11:09:55 | tsbere | jeff: Subquery or group by would work. array_agg, or string_agg. |
| # | 11:10:06 | mrpeters-isl | yeah. looks like a cool tool. just have to figure out how to get it to handle apache logs that are broken up daily :( |
| # | 11:10:29 | bshum | mrpeters-isl: I'm pretty sure that's why we never got as far with awstats |
| # | 11:10:41 | bshum | mrpeters-isl: Someone installed it once here, cause I found remnants of it on the servers |
| # | 11:11:20 | mrpeters-isl | i'm sure it can be done. i was thinking a bash script with a date variable using "date" utility to tell the cron job where to find the logs but i wasn't sure if awstats would handle that and combine them into the monthly log |
| # | 11:12:13 | jeff | tsbere: i'm not sure how to do it with group by. i can do a simple: select array_agg(post_code) from actor.usr_address where usr = 123; |
| # | 11:12:49 | bshum | mrpeters-isl: Trickier thing for us has been trying to get it granular on a per library basis while everyone shares a single URL. Really sucks trying to count out exactly how many per library. |
| # | 11:13:01 | bshum | mrpeters-isl: Though hopefully you don't have to face that. |
| # | 11:13:10 | tsbere | jeff: Table joins. array_agg in your column list as you are doing so there. You just group by all the other result columns and array_agg will only pick up on the results in that group. |
| # | 11:13:19 | frank_ has quit IRC |
| # | 11:13:45 | jeff | oh. right! i wasn't thinking of it as an aggregate function like sum(), count(), etc |
| # | 11:14:01 | tsbere | heh |
| # | 11:14:16 | tsbere | jeff: And depending on how you intend to use the data, you may want to look into string_agg |
| # | 11:15:16 | Dyrcona | While working on getting Evergreen installed on Precise Pangolin, I've noticed we're installing a CPAN module on Lucid Lynx that isn't needed by Evergreen. I've deleted that from the Makefile.install. |
| # | 11:15:40 | bshum | tsbere: string_agg is a PG 9.0 thing? |
| # | 11:15:44 | gmcharlt | Dyrcona: which one? |
| # | 11:15:49 | bshum | Well, 9.0+ |
| # | 11:15:54 | Dyrcona | XML::RPC |
| # | 11:16:13 | Dyrcona | gmcharlt: Evergreen doesn't reference it, but it does use RPC::XML. |
| # | 11:16:20 | tsbere | bshum: You know, it might be. I ignore pre-9.0 these days. |
| # | 11:16:47 | bshum | tsbere: Our production is still in 8.4 land. Hoping to get up to 9.x sometime early next year. |
| # | 11:17:07 | bshum | tsbere: Sounds like a neat option for our future though |
| # | 11:17:28 | Dyrcona | bshum: The ubuntu-precise target will install 9.1 psql clients. |
| # | 11:17:37 | tsbere just created an empty bib record by not filling in any marc fields |
| # | 11:19:40 | Dyrcona | gmcharlt: I think that slipped in during the confusion of trying to get the XML-RPC gateway working on Lucid. A sort of cargo cult thing: we installed it and things worked after, so we added it to the Makefile. |
| # | 11:21:16 | Dyrcona | After I get a stock master installed and mostly working, I'll revisit the XML-RPC on Lucid. I think we will need to install RPC::XML from CPAN to replace the broken one that comes with Lucid, unless it has since been updated. |
| # | 11:21:38 | gmcharlt | gotcha |
| # | 11:28:40 | tsbere | Anyone have thoughts on this before I run over to launchpad with it? http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/hold_status_suspended |
| # | 11:43:44 | phasefx | tsbere++ |
| # | 11:44:06 | tsbere is tired of getting "why aren't these holds filling?" when they are suspended |
| # | 11:45:07 | phasefx | I think we may even want to backport that |
| # | 11:45:45 | bshum | +1 :D |
| # | 11:48:25 | tsbere | https://bugs.launchpad.net/evergreen/+bug/901767 |
| # | 11:49:13 | tsbere | Nominate away ;) |
| # | 11:49:24 | tsbere | Or just target. Whichever. ;) |
| # | 12:01:11 | tsbere notes that bshum decided to go for broke and target clear back to 2.0 |
| # | 12:06:23 | bshum | Well, that's where I'll start testing it. |
| # | 12:06:34 | bshum | But we can always drop that ;) |
| # | 12:11:57 | tsbere | test away! ;) |
| # | 12:14:48 | tsbere | heh. "This bug affects you and 1 other person" - That didn't take too long ;) |
| # | 12:15:25 | bshum | Oh that's probably me :) |
| # | 12:15:35 | tsbere was assuming it was |
| # | 12:15:36 | bshum | I always click "affects me" on certain bugs I want to track. |
| # | 12:15:49 | bshum | Otherwise I end up losing sight of them |
| # | 12:16:16 | Dyrcona | I think its a good idea as clicking affects me is one way to raise the heat on a bug. |
| # | 12:16:38 | moodaepo | haet_on_bug++ |
| # | 12:16:44 | moodaepo | Or heat even |
| # | 12:17:13 | bshum | Burn in righteous fury? |
| # | 12:17:52 | moodaepo | bshum++ righteous glory |
| # | 12:18:52 | bshum | Doh, misquoted "Burn in righteous fire!" |
| # | 12:19:49 | tsbere is amazed how often people jump on what he sees as the simple stuff that he wasn't even sure was worth doing |
| # | 12:20:09 | tsbere | Although in this case this was 100% worth doing just to get the constant tickets about it to stop. <_< |
| # | 12:20:41 | bshum | Yeah I'm asking our staff here whether this is even a thing right now. I actually think folks aren't making enough use of the suspended holds options. |
| # | 12:21:04 | bshum | They're still boggled with other holds-related issues. |
| # | 12:23:05 | tsbere | For us it comes up as a "why did this skip these holds that should have filled and jump into transit instead?" type question. A lot. |
| # | 12:30:19 | bjwebb has joined #evergreen |
| # | 12:32:51 | bshum | tsbere: Well I think we've finally gotten holds somewhat more sensible now that we recognize how much the hold target is lying to us. |
| # | 12:33:02 | tsbere | heh |
| # | 12:33:25 | bshum | tsbere: I'm currently blaming that mess on libraries not checking pull lists but once a week, or deliveries taking extra days beyond expectations. |
| # | 12:33:37 | bshum | Or just otherwise not filling holds on a regular basis. |
| # | 12:33:40 | tsbere | ahh |
| # | 12:36:06 | mrpeters-isl | 404 Document Not Found (hits on favicon excluded) 1,097,651 98.3 % 448.27 MB |
| # | 12:36:11 | mrpeters-isl | thats 1 day's apache logs from Evergreen |
| # | 12:36:26 | mrpeters-isl | seems like a LOT of hits that result in 404's |
| # | 12:36:32 | bshum | Ouch. |
| # | 12:36:34 | moodaepo | heh |
| # | 12:36:43 | bshum | Weird nls stuff going on still? |
| # | 12:36:47 | tsbere | A lot of language files, for example, are checked for even if they are normally never there... |
| # | 12:36:47 | mrpeters-isl | but we have 791225 to address that |
| # | 12:37:13 | bshum | Yeah jamesrf showed us some of that and how to do symbolic links to fix a whole bunch of those errors. |
| # | 12:37:15 | mrpeters-isl | yeah, no big deal...it was just sort of funny when i saw that number |
| # | 12:37:22 | bshum | Can't remember where/how now of course |
| # | 12:37:43 | plux has joined #evergreen |
| # | 12:37:49 | jamesrf | meh i don't either, i don't think that's an ideal solution, there should be a way to make Dojo not do that |
| # | 12:38:43 | tsbere | Step 1 may be "update dojo" <_< |
| # | 12:40:39 | dbs has joined #evergreen |
| # | 12:43:31 | tsbere is reminded, as he reads his email, that dbs doesn't like playing with holds |
| # | 12:44:42 | dbs | guilty as charged |
| # | 12:45:07 | Rural has joined #evergreen |
| # | 12:46:40 | bshum | Every time someone adds a new A/T, it's like waiting for the next day's logs to find out whether they royally screwed something up. |
| # | 12:47:20 | bshum | Environment path settings are such fickle things |
| # | 12:47:22 | Dyrcona | gmcharlt: RPC::XML::Function needs to be installed. |
| # | 12:50:42 | plux has quit IRC |
| # | 12:50:59 | plux has joined #evergreen |
| # | 12:53:29 | plux has quit IRC |
| # | 12:54:04 | plux has joined #evergreen |
| # | 12:54:16 | copystar has joined #evergreen |
| # | 13:01:12 | Dyrcona | gmcharlt: Yep, just installing RPC::XML::Function on Ubuntu seems to fix the problems with XML-RPC. |
| # | 13:02:34 | Rural | Do Evergreen's version number work like Linux? Is 2.1 the development version and 2.0 the stable version? |
| # | 13:02:50 | tsbere | They work nothing like Linux. |
| # | 13:03:07 | tsbere | They also work nothing like our own docs say they should, near as I can tell ;) |
| # | 13:03:44 | Rural | Ha! So what which version would a new user want to install? (I'm expecting, "It depends.") |
| # | 13:04:08 | tsbere | Personally I recommend "master". But a lot of people aren't comfortable with that, so next on the list would be 2.1 |
| # | 13:04:14 | bshum | From the downloads page: "Currently the latest release from the Evergreen 2.1 series is recommended for new installations andstable releases are suggested for production systems." |
| # | 13:04:40 | Dyrcona | Rural: You want to git clone git://git.evergreen-ils.org/Evergreen.git and run the master branch from that. |
| # | 13:05:15 | Rural | Ok. I'll finish prepping a VM and go with master. |
| # | 13:05:51 | Dyrcona | Yeah, if our versions actually worked like our docs say they should 2.1 would be 3.0 and 2.2 would be 4.0. |
| # | 13:06:32 | Dyrcona | Rural: Out of curiosity, what flavor of VM are you prepping? |
| # | 13:07:40 | Dyrcona | I am working on build fixes for Ubuntu Lucid Lynx (10.04) and Precise Pangolin (12.04). |
| # | 13:08:29 | Dyrcona | So, if you're installing on Ubuntu, I can point you to a git branch that should work a little better than master currently does. |
| # | 13:08:34 | jeff | tsbere: slightly annoying: string_agg() does not do any escaping of delimiters -- so foo-bar,baz with a comma delimiter is fine, but with a hyphen it ends up foo-bar-baz. |
| # | 13:08:55 | jeff | I guess the answer there is know your data, or do some string replacing before string_agg |
| # | 13:09:16 | tsbere | jeff: Given that you may *want* to have that happen, yea. ;) |
| # | 13:10:27 | jeff | happily, we have zero post_code values containing | (though there are 10 which contain a comma :P) |
| # | 13:11:43 | bshum | What no barcodes as ZIP? |
| # | 13:11:48 | Rural | Dyrcona: It's KVM VM, running Debian. But I could switch gears in a hurry. |
| # | 13:12:08 | Dyrcona | Rural: No. Don't change on my account. Debian should be fine. |
| # | 13:12:17 | jeff | bshum: item barcodes as email address -- yep |
| # | 13:12:34 | Dyrcona | Rural: Ubuntu builds just fine, but XML-RPC is broken in master at the moment on Ubuntu. |
| # | 13:13:10 | Rural | Dyrcona: Gotcha. Debian 6.0.3 ok? |
| # | 13:13:35 | Dyrcona | Rural: If that's Lenny or Squeeze, you'll be fine. (Think it is Squeeze.) |
| # | 13:14:24 | Dyrcona | Yep, that's Squeeze. So go for it. |
| # | 13:16:11 | Rural | Will do. |
| # | 13:17:50 | Rural | On another note, does anybody here have experience with the Horizon ILS? One of our librarians in the direction. |
| # | 13:18:21 | bshum points at Dyrcona |
| # | 13:19:08 | Dyrcona | Rural: I do, unfortunately. |
| # | 13:19:52 | Dyrcona | brb |
| # | 13:20:33 | tsbere limits his experience in Horizon he is willing to admit existing to something along the lines of "how to blow the servers out to replace them with evergreen" |
| # | 13:24:02 | Dyrcona | heh |
| # | 13:24:46 | Rural | I'm sensing that there isn't a lot of love for Horizon around here. |
| # | 13:25:30 | Rural | Maybe we could move the discussion somewhere where it won't be off-topic. |
| # | 13:25:56 | Dyrcona | Rural: There's a #sdtechshare channel. |
| # | 13:26:30 | Dyrcona | Are your questions strictly about Horizon or do they relate to comparing Evergreen and Horizon? |
| # | 13:28:27 | Rural | A comparison would nicely avoid straying off-topic. |
| # | 13:28:51 | tsbere | I don't think we actively avoid going off-topic unless there is a meeting going on in here. >_> |
| # | 13:29:00 | Dyrcona | :) |
| # | 13:29:17 | bshum vaguely recalls the bacon conversation that happened DURING a meeting. |
| # | 13:30:30 | Rural | My situation is that our school division desperately needs a division-wide library system. I've been struggling to get time to set up Evergreen. |
| # | 13:31:01 | Dyrcona | Rural: How many libraries? |
| # | 13:31:10 | Rural | An overzealous librarian has been in touch with an organization that runs a Horizon system and sells access to libraries/schools. Access isn't cheap. |
| # | 13:31:21 | Rural | Eight. |
| # | 13:31:26 | Dyrcona | Horizon is essentially a dead product. |
| # | 13:31:34 | Rural | Yay! |
| # | 13:31:46 | dbs | Revamped http://evergreen-ils.org/dokuwiki/doku.php?id=dev:git to emphasize pushing branches to working repo instead of attaching patches |
| # | 13:31:56 | Dyrcona | dbs++ |
| # | 13:32:14 | dbs | tsbere / gmcharlt might get 3 or 4 ssh pubkey requests |
| # | 13:32:31 | Dyrcona | Rural: If you loan rules are identical, then you might want to look at Koha. |
| # | 13:32:33 | tsbere is working on one now |
| # | 13:32:39 | dbs | tsbere++ |
| # | 13:33:41 | Dyrcona | When I last looked at Koha, around version 3.0/3.2, it didn't have the consortial features that we needed, but for smaller consortia with more uniform rules and administration, it seemed like it would work. |
| # | 13:33:49 | Dyrcona | I also hear it is easier to set up. |
| # | 13:34:23 | dbs | It's packaged in Debian! |
| # | 13:34:31 | Dyrcona | Where's gmcharlt when you need him? |
| # | 13:35:23 | dbs | rangi is probably sleeping |
| # | 13:36:12 | rangi | nope |
| # | 13:36:13 | Rural | Koha looks like it is controlled by a single company. That's a negative but something we can live with as long as everyone plays fair. Are there more than a couple major players with Evergreen? |
| # | 13:36:27 | rangi | thats bs rural |
| # | 13:36:32 | tsbere loves having worked all the bugs out of his windows git install as far as doing everything on the command line, compared to needing the GUI |
| # | 13:36:33 | Dyrcona | Rural: No, community koha is compeletely open. |
| # | 13:36:38 | rangi is on the bus |
| # | 13:36:44 | Rural | Fair enough. |
| # | 13:36:49 | rangi | koha-community.org |
| # | 13:37:11 | rangi | there is one hostile company who run that other site |
| # | 13:37:18 | rangi | they do their own thing tho |
| # | 13:37:19 | Rural | Gotcha. |
| # | 13:37:37 | Rural | And Evergreen? Strong community? |
| # | 13:37:55 | Dyrcona | This is pretty much the community for Evergreen, this and the mailing lists. |
| # | 13:37:58 | rangi | getting stronger all the time |
| # | 13:38:35 | Dyrcona | We're very open to new contributors here. |
| # | 13:38:38 | rangi only lurks on the fringes |
| # | 13:38:49 | rangi | but the fringes are getting bigger |
| # | 13:39:16 | rangi | I hung out with awesome EG guys from sitka in vancouver |
| # | 13:39:41 | rangi | I think since both projects changed to git |
| # | 13:39:52 | rangi | easier to become a developer |
| # | 13:40:01 | Rural | I feel a bit off-balance. It's funny how Open Source folk recommend one-another's projects. |
| # | 13:40:52 | rangi | debian.koha-community.org btw |
| # | 13:41:04 | Rural | Ok. So forget Horizon. Any major reasons why I would choose one of Koha or Evergreen over the other? (In addition to the above.) |
| # | 13:41:31 | phasefx | Koha has all web-interfaces |
| # | 13:41:32 | Rural | rangi: Yup. I'm there, and I'm cloning my VM. |
| # | 13:41:55 | phasefx | which is a pro and con, but mostly a pro |
| # | 13:42:16 | rangi | do you do course reserves? |
| # | 13:42:17 | rangi | koha proper doesn't have that yet |
| # | 13:42:33 | rangi | hopefully 3.8 in april |
| # | 13:42:41 | csharp | Rural: I would try setting up demo environments of each and trying each out with small datasets |
| # | 13:42:45 | tsbere | phasefx: I dunno about that. I see that as a potential bigger con. :P |
| # | 13:43:24 | rangi | yeah platform indepence for the lose. ,,, oh wait what? *grin* |
| # | 13:43:43 | rangi | hmm I can't type, need coffee? |
| # | 13:43:50 | rangi | and sleep |
| # | 13:43:58 | jamesrf | btw xulrunner seems gone from http://releases.mozilla.org/pub/mozilla.org/ |
| # | 13:44:10 | csharp | rangi: we have a booking module that provides some basic course reserves functionality |
| # | 13:44:18 | bshum | jamesrf: I think mrpeters-isl said something about using the FTP to get that now |
| # | 13:44:20 | Dyrcona | jamesrf: mrpeters-isl mentioned that the other day. |
| # | 13:44:27 | Dyrcona | check the irc logs. |
| # | 13:44:27 | phasefx | arbitrary peripheral support is harder with web, but you could tie yourself to a specific browser and use plugins/extensions/etc |
| # | 13:44:31 | csharp | since I'm in a public library consortium, we don't have use for it |
| # | 13:44:49 | jamesrf | ah thx |
| # | 13:45:09 | rangi | csharp: yep I had seen emily carrs one, so was warning rural koha doesn't have that |
| # | 13:45:33 | csharp | rangi: oh - got it;-0 |
| # | 13:46:32 | rangi | and yeah circ rules in koha is only a 3x3 matrix |
| # | 13:46:54 | Rural | Cool. This has given me a lot to chew on. Looks like Koha will set up in a giffy. That may be the deciding factor. (I've spent days trying to get Evergreen set up.) |
| # | 13:46:55 | rangi | branch/library by itemtype by borrowertype |
| # | 13:47:11 | phasefx | Rural: offline mode important? bookmobiles? |
| # | 13:47:12 | Dyrcona | Rural: That's a bonus point in Koha's favor. |
| # | 13:47:13 | rangi | not as flexible as evergreen |
| # | 13:47:44 | Dyrcona | Rural: My suggestion is generally that people go with Koha unless they know they need something that Evergreen does that Koha doesn't. |
| # | 13:48:35 | phasefx | it's of course worth trying both out (through public demo servers etc.) You may like the feel of one over the other, and installation is a one-time or infrequent pain :) |
| # | 13:48:50 | Rural | Thanks all for the suggestions. I'll go to work and share anything I figure is of value here. |
| # | 13:49:26 | jeff has quit IRC |
| # | 13:53:09 | kmlussier has joined #evergreen |
| # | 13:59:01 | bshum | jamesrf: Around? Curious if you know anything about how your org's setup for IdeaTorrent was done. |
| # | 13:59:18 | jamesrf | i can try to answer sure |
| # | 13:59:33 | bshum | Was just wondering if you ended up setting up anything more complex with the code itself. |
| # | 13:59:41 | bshum | I found remnants of its bzr tracks |
| # | 13:59:52 | bshum | And it looked like someone has been throwing in a few commits over the last two years |
| # | 14:00:04 | bshum | But not really sure what the status is since so many pages declare it dead |
| # | 14:00:25 | bshum | Was wondering if you guys had done anything with either bzr or git |
| # | 14:00:25 | jeff has joined #evergreen |
| # | 14:00:25 | jeff has joined #evergreen |
| # | 14:00:35 | bshum | In relation to the project code |
| # | 14:01:13 | bshum | We're thinking to start poking around and customizing certain elements. |
| # | 14:01:19 | Dyrcona | bshum: Play Dr. Frankenstien, raise it from the dead. |
| # | 14:01:34 | Dyrcona | "We can fix him. We have the code." |
| # | 14:02:03 | jamesrf | yeah we've made a number of modifications although they are not yet tracked in any rcs unforunately |
| # | 14:02:21 | bshum | jamesrf: The solutions part is strange, I'm interested to learn how you guys came up with such a clean unified approach to written solutions. Like having everything read off as "Being developed by Sitka team" etc. Or if that's just training and how you guys taught folks to enter information. |
| # | 14:03:03 | bshum | The default module seems to allow for free text there, could see all sorts of random thoughts being entered. |
| # | 14:03:31 | jamesrf | no we aren't using it really in the way it was intended, instead libraries just submit things and vote on them |
| # | 14:03:44 | jamesrf | they don't really propose solutions because often they don't understand what the solution would be |
| # | 14:03:57 | jamesrf | or their idea is the solution, ie: "make the button bigger" is the idea |
| # | 14:03:57 | bshum | Yeah, I could see the same thing for us. |
| # | 14:04:47 | jamesrf | i think often they need to think "what is the problem making the button bigger solves" |
| # | 14:05:11 | jamesrf | but it's often too much to ask for that in our case |
| # | 14:05:23 | jamesrf | they would rather we figure that part out |
| # | 14:05:34 | bshum | Makes sense. |
| # | 14:05:36 | csharp | jamesrf: yep ;-) |
| # | 14:05:55 | bshum | Did you guys hack the submission forms so that solutions weren't required? Or just edit whatever came through for consistency's sake? |
| # | 14:06:12 | bshum | Or only certain approved people input ideas collected, for later voting purposes |
| # | 14:06:37 | bshum | (just pondering) |
| # | 14:06:43 | jamesrf | no we just ask them to put "no solution" in there or something when they submit it |
| # | 14:06:53 | bshum | Ah, reasonable. |
| # | 14:07:02 | jamesrf | if you click on the "sandbox" you can see what they are doing there |
| # | 14:07:34 | bshum | Ahh, I see now. |
| # | 14:07:46 | bshum | So then at the next level once approved, you can edit the solution entry. |
| # | 14:07:50 | bshum | And then have folks vote |
| # | 14:07:56 | bshum | Nifty |
| # | 14:08:21 | jamesrf | we've sorta modified the voting system a bit as we have weighted voting |
| # | 14:09:55 | bshum | Well, we're only in early stages of toying around with. |
| # | 14:10:06 | jamesrf | we have a template also that the idea form is prepopulated with, you can see it in some of the ideas |
| # | 14:10:25 | bshum | Took me most of the last two days figuring out how to get Drupal going on one of our local servers. |
| # | 14:10:37 | bshum | But this is a very interesting approach |
| # | 14:10:51 | dbs | senator: just merged current origin/master into the "saner TPAC layout branch" - kinda hoping to build on that for some of the work |
| # | 14:10:53 | jamesrf | i think it's a bit kludgey but there's not many options out there |
| # | 14:11:24 | dbs | we've spent a good chunk of the day with some Evergreen / TPAC dev basics, sorting out SSH keys and git stuff, and are _almost_ ready to start coding :) |
| # | 14:12:18 | bshum | jamesrf: Cool, thanks for sharing, I'd be curious to learn how you modified your code for the prepopulated form data. |
| # | 14:12:22 | jeff | dbs: congrats! |
| # | 14:12:29 | bshum | jamesrf: But maybe a bit later. |
| # | 14:12:37 | senator | dbs++ |
| # | 14:13:04 | bshum | Yay dbs! |
| # | 14:13:51 | senator | working/collab/dbs/tpac-non-fixed-width is the branch you refer to... yes it is |
| # | 14:14:39 | jamesrf | bshum: i didn't do it myself but let me know and i can poke the person responsible into joining this channel |
| # | 14:14:53 | senator | looking forward to the end of lots of inline css and needless dom cruft |
| # | 14:30:03 | edoceo | I want to email patrons a due date message, on checkout. -> Action Triggers or .... ? |
| # | 14:37:05 | edoceo | Also, how hard to make an application that sits in OpenSRF that is based on PHP? |
| # | 14:37:06 | tsbere | I dunno how easy it is to do that with action/trigger |
| # | 14:37:19 | edoceo | is there a better way? |
| # | 14:37:40 | tsbere | I think if you copy the 3 day pre-due notice and tweak it a little you might get what you want |
| # | 14:37:57 | tsbere | Things like telling it to use the checkout time instead of the due date and have no offset |
| # | 14:38:18 | bshum | It's still only fire as often as the script runs |
| # | 14:38:25 | bshum | Unless it was somehow an on-demand one? |
| # | 14:38:27 | edoceo | I want to have it fire every checkout |
| # | 14:38:43 | bshum | Kind of like how the pull lists are generated. |
| # | 14:38:49 | bshum | Or printing self check receipts |
| # | 14:38:50 | tsbere | Run things every 15 min. Then every 15 min it will batch-send the stuff from the last 15 min |
| # | 14:38:52 | edoceo | Scan, Scan, Scan -> complete checkout -> hey! I got an email from Lib about due date |
| # | 14:40:08 | bshum | The only way to define a complete checkout would be what? Hitting the "done" button? |
| # | 14:40:41 | edoceo | I suppose, I don't know the answer there. |
| # | 14:40:45 | bshum | So maybe tie some sort of trigger event off the button. |
| # | 14:41:20 | bshum | Just thinking it'd be hard to accurately predict otherwise when a series of checkouts had been "finished" |
| # | 14:42:19 | edoceo | Surely some server-side process is executed when a Patron complete a checkout - yea? Would I have to hook in there? |
| # | 14:43:43 | dbs | So - one email per item checked out? |
| # | 14:44:12 | edoceo | I'm thinking one email, with a list of the items ordered by due date |
| # | 14:44:12 | jeff | action/trigger events have a logic for grouping them, iirc. |
| # | 14:44:17 | Dyrcona | dbs: I think he wants 1 email for everything that the patron checks out in a "session" |
| # | 14:44:25 | edoceo | Dyrcona: yep |
| # | 14:45:23 | jeff | "Processing Group Context Field", in the event definition looks like what i was thinking of. |
| # | 14:45:26 | dbs | All you need to do is define what a session is then, and teach Evergreen to understand that, and associate a hook with it, I think. |
| # | 14:45:48 | edoceo | So, perhaps that is not so easy? |
| # | 14:45:49 | dbs | jeff: oh sure, you can group by user, just like overdues etc. |
| # | 14:45:56 | dbs | perhaps |
| # | 14:46:14 | bshum | Well, each checkout would fire off individually I think. But then get grouped together like tsbere described if the A/T running was staggered to allow for events to build together. |
| # | 14:46:19 | dbs | 1 email per checkout, easy |
| # | 14:46:26 | dbs | 1 email per user per day, pretty easy |
| # | 14:46:48 | dbs | (or "per interval" I guess) |
| # | 14:46:52 | edoceo | 1 email per checkout == 1 email per item checked out at the counter - so three books => three emails ? |
| # | 14:46:54 | tsbere | Rig the "fire off the create events" to "clicked on 'done'" |
| # | 14:47:08 | jenny has left #evergreen |
| # | 14:47:15 | dbs returns focus to tpac |
| # | 14:47:17 | jenny has joined #evergreen |
| # | 14:48:04 | bshum | edoceo: That's correct. If you were basing it literally on each item checkout. |
| # | 14:48:06 | jeff | processing delay of X minutes, run checkout action triggers every X-1 minutes, done? |
| # | 14:48:57 | edoceo | jeff: with that I can run my process every 30 minutes, when a Patron has something checked-out, I look at all their items an issue an email? |
| # | 14:48:58 | jeff | i suppose that would depend on the grouping logic when it interacts with processing delay -- is it the first or the last event? |
| # | 14:49:47 | jeff | edoceo: i'm thinking that action triggers would do the trick, possibly with a little modification. this is the only documentation i know of, other than the code itself: http://docs.evergreen-ils.org/2.0/draft/html/actiontriggers.html |
| # | 14:50:11 | bshum | Seems to me that would mean generating A/T events with process-hooks very often |
| # | 14:50:21 | bshum | Well, more than once per day |
| # | 14:50:32 | bshum | Which I guess you could do if you applied varying granularity. |
| # | 14:51:01 | edoceo | Yes, but perhaps we could email patrons once a day - like at EOD I can run a process that collects all patron/checkout data and sends out a bundle of emails at that time? |
| # | 14:51:17 | phasefx | could just fire an event on the Done button, sending data directly from the client-side list |
| # | 14:51:35 | edoceo | Doesn't that requres update tho the staff-client? |
| # | 14:51:48 | phasefx | send the circ id's to a template which runs on the spot. An update of server-side staff client files, yes |
| # | 14:51:57 | phasefx | but not a whole lot of work |
| # | 14:52:03 | edoceo | I like this idea |
| # | 14:52:17 | jeff | i don't think i'd focus on the Done button. I never use it, for one. |
| # | 14:52:24 | phasefx | add a checkbox for e-mail receipt |
| # | 14:52:44 | edoceo | So, I dig around the XUL, find some events that are reasonable and use those to trigger some additional server side action to send the email? |
| # | 14:52:56 | jeff | So you'd need a "fire when about to close this tab / about to load a new patron / about to close window / about to close staff client" bit. |
| # | 14:54:18 | jeff | I just wouldn't recommend relying on the Done button. Either find another trigger, or have a process for catching the ones that were not sent because the Done event wasn't triggered due to a difference in use of the UI. |
| # | 14:55:30 | phasefx | could use onunload |
| # | 14:55:53 | phasefx | though I really don't like using that |
| # | 14:56:40 | phasefx | using Done could be a "matter of training" |
| # | 14:56:51 | edoceo | Hm, yea, and now it seems like it's putting some logic on that client side |
| # | 14:57:17 | plux has quit IRC |
| # | 14:57:19 | edoceo | I was hoping that there was some event in-side the system where when some user completes a checkout of multiple items I could hook in there? |
| # | 14:57:50 | phasefx | I'd just use grouping as mentioned by others |
| # | 14:57:52 | edoceo | IDK, like some checkout_items_complete() event in Circ.pm or something silly |
| # | 14:58:01 | phasefx | not perfect, but you're not going to miss anything |
| # | 14:58:34 | phasefx | a template that groups circs associated with fired checkout events |
| # | 14:59:27 | edoceo | So, in Evergreen the "checkout" is an event that happens per item? Not that happens once to group of items? Is that how it works? |
| # | 14:59:47 | phasefx | it's one of things A/T was designed for. EG just doesn't have a notion of "checkout session" |
| # | 15:00:50 | phasefx | every scan of an item barcode is making an api call to a checkout method. I'm unsure if we're actually firing an A/T event or not for checkout, but we could easily tack that behavior onto that checkout method |
| # | 15:01:38 | edoceo | In my Trigger Hooks is an item called 'checkout' - "Item checkout out to user" |
| # | 15:01:43 | tsbere | I think checkout based hooks are handled by A/T without events firing |
| # | 15:01:54 | bshum | "checkout" is a hook |
| # | 15:02:35 | phasefx never gets passive/active events straight without reference |
| # | 15:02:48 | bshum | I wonder if it's possible to reuse elements from other areas |
| # | 15:02:49 | edoceo | checkout says passive in my setup |
| # | 15:03:23 | phasefx | either way, you can do what you want, as long as you're willing to define checkout session as "circs that happened within a certain timeframe of each other for a given user" |
| # | 15:03:33 | edoceo | Yea, I'll do that |
| # | 15:03:49 | dbs going to try adding "circ.due_date" to in-db unapi so we can replace the monster json_query in record detail display |
| # | 15:04:15 | edoceo | Then I can make a Tirgger Event on Item Checkout + 15 minutes so that 15 minutes after the last item-checkout I can fire this event? |
| # | 15:04:30 | edoceo | But I'll need some queue there or something? |
| # | 15:04:32 | phasefx | no |
| # | 15:04:43 | bshum | Probably should fire immediately. |
| # | 15:05:05 | bshum | And then set the action_trigger_runner script to run at the interval you desire. |
| # | 15:05:10 | bshum | With the appropriate options |
| # | 15:05:20 | edoceo | I'm confused |
| # | 15:05:38 | phasefx | unless I'm misunderstanding, you'd define an action_trigger.event_definition (your template lives there). It'll have a hook of checkout, a group field of usr, and a delay of 15 minutes |
| # | 15:06:02 | Dyrcona | Error loading database driver [pgsql] <- Guess that means libdbi has a problem. |
| # | 15:06:07 | phasefx | the checkout hook has a core type of circ, so that's what you're dealing with. The usr field is coming off of the circs |
| # | 15:06:25 | phasefx | so your template will get targets that are circs that get grouped together by usr |
| # | 15:06:29 | bshum | edoceo: From the docs: http://docs.evergreen-ils.org/2.0/draft/html/ProcessingActionTriggers.html |
| # | 15:06:39 | bshum | That page explains how action triggers run |
| # | 15:06:45 | bshum | or some of the options rather. |
| # | 15:07:16 | bshum | So what'll happen is that you have to run --process-hooks at least on a regular enough basis to generate all the various A/T entries. |
| # | 15:07:23 | bshum | Based on the definition you set up. |
| # | 15:07:36 | bshum | Then you have to make sure that's all completed before the next time the --run-pending happens. |
| # | 15:07:43 | bshum | Otherwise, it won't actually send anything. |
| # | 15:07:48 | edoceo | Drat |
| # | 15:08:08 | bshum | That's part of the normal cron setup for most Evergreen systems. |
| # | 15:08:23 | bshum | I think there are examples |
| # | 15:08:32 | edoceo | Yes, I have seen some |
| # | 15:09:00 | edoceo | I'm still a bit confused about how this process will run |
| # | 15:09:42 | edoceo | Patron goes to do checkout of four books, that creates four checkout events, then my A/T runs and sees those four events (grouped by usr) ? Is that what it does? |
| # | 15:10:54 | bshum | That sounds right to me, based on my limited interaction with current A/Ts |
| # | 15:11:45 | tsbere | Closer to "A/T sees that there are 4 events for that definition grouped on a field that they all share and runs them all as though they were one" ;) |
| # | 15:11:58 | bshum | tsbere++ |
| # | 15:12:01 | tsbere | Provided they are all valid at the time, anyway |
| # | 15:12:19 | tsbere | If three of them are valid (based on the delay) and one isn't then only the three valid ones will be looked at |
| # | 15:14:08 | jeff | and will the delay be calculated off of the earliest or the latest event? |
| # | 15:14:35 | bshum | Each one individually |
| # | 15:14:41 | bshum | As far as I know |
| # | 15:14:51 | jeff | seems that latest would be most useful when grouping at all, but i don't know the complete set of uses. |
| # | 15:15:07 | tsbere | jeff: Each individually, as bshum said. |
| # | 15:15:11 | bshum | That's why I think the shortest delay possible would group better |
| # | 15:15:13 | jeff | got it. |
| # | 15:15:17 | bshum | Based on whenever the cron runs the script |
| # | 15:15:18 | tsbere | Otherwise you would *never* get, say, overdue notices. |
| # | 15:15:23 | tsbere | ;) |
| # | 15:15:40 | bshum | I think I learned how that worked based on hold notifications. |
| # | 15:15:42 | tsbere | Note that delay can be negative (pre-due notices) |
| # | 15:15:54 | jeff | i haven't looked into A/T overdues. those both base off of that? seems... hrm. |
| # | 15:15:58 | jeff will dig later |
| # | 15:16:16 | tsbere | positive delay based on due date = "overdue by X days" |
| # | 15:16:24 | tsbere | negative delay based on due date = "predue" |
| # | 15:16:47 | tsbere | If you were to create one with a positive delay based on the checkout time you could send due date emails that way |
| # | 15:16:47 | phasefx | EG, flexible, but complicated :) |
| # | 15:17:26 | tsbere would lean toward delay of X, run cron every 2X though |
| # | 15:19:06 | tsbere | Even that isn't guaranteed to work well, though. :( |
| # | 15:19:30 | Dyrcona | Whee! More emails for our AOLusers to erroneously flag as spam! |
| # | 15:21:29 | tsbere | Huh, checkout.due is passive. checkout isn't, and is created outright by the checkout code. Also, renewals may fire differently than straight checkouts in that regard.....and require a new event *and* email to go out. |
| # | 15:22:33 | jeff | Dyrcona: do you remove the email address from the patron account when that happens, and note "user marked as spam -- get new email address from patron" as an alert? :-) |
| # | 15:22:50 | tsbere | jeff: I disagree |
| # | 15:23:06 | jeff | tsbere: with what? |
| # | 15:23:10 | Dyrcona | jeff: No, because AOHell strips the recipient address from the spam report so we can't do that. |
| # | 15:23:17 | tsbere | jeff: You put an alert saying "user can't tell difference between delete and spam buttons - NEVER ALLOW AN EMAIL ON THIS ACCOUNT AGAIN" ;) |
| # | 15:23:41 | Dyrcona | yep, ID10T error. |
| # | 15:23:53 | Dyrcona | Oh, wait..... I signed something..... |
| # | 15:24:41 | jeff | email addresses are mis-entered or change. it isn't always the receiving user's 'fault' that you get a spam notice. just be thankful that aol gives you any feedback loop. :-) |
| # | 15:24:53 | kmlussier has quit IRC |
| # | 15:25:09 | StephenGWills has joined #evergreen |
| # | 15:26:07 | Dyrcona | jeff: It's useless. We only signed up to get them because AOL basically required it to continue to accept mail from us a few years ago. |
| # | 15:26:29 | Dyrcona | ILS email notifications look surprisingly a lot like spam to most heuristics. |
| # | 15:27:12 | Dyrcona | Well, since the install from source libdbi doesn't work on Precise Pangolin, I'm now trying the packaged libdbi and libdbdpgsql. |
| # | 15:27:36 | tsbere | Has something to do with "we keep seeing emails that match this pattern coming from you. Because it keeps matching the pattern and people mark it as spam every so often it must *all* be spam and those just deleting it aren't paying enough attention" |
| # | 15:28:28 | Dyrcona | Yeah, I'm surprised that anyone gets automated emails from their library, ever. |
| # | 15:28:46 | Dyrcona | No matter the ILS. |
| # | 15:29:17 | kmlussier has joined #evergreen |
| # | 15:31:22 | Dyrcona | Heh, libdbdpgsql from packages works and one installed from source doesn't! |
| # | 15:31:39 | Dyrcona | pangolin++ |
| # | 15:33:34 | dbs | Dyrcona: the only reason we were using source was because squeeze and lucid were frozen before the fix we needed got into libdbi, so that's good |
| # | 15:34:27 | Dyrcona | dbs: ok. the ubunut install for Evergreen is going to look very different after I'm done with it. I'm installing as much from debs as is possible. |
| # | 15:34:40 | dbs | Dyrcona: that's always been the goal |
| # | 15:34:48 | Rural has quit IRC |
| # | 15:35:12 | csharp | debs++ |
| # | 15:36:05 | Dyrcona | At this point, only 4 modules are installed via CPAN on precise pangolin. Everything else comes from debs. |
| # | 15:36:07 | dbs | happy to see someone else finally doing something with Makefile.install |
| # | 15:36:29 | Dyrcona | happy to help. |
| # | 15:37:22 | dbs | Cool. BTW, the reason "generic_ubuntu" was there is because until recently it served as base for both hardy and lucid |
| # | 15:37:27 | Dyrcona | Sorry 5 modules. I forgot about SpiderMonkey. |
| # | 15:37:55 | bshum | Just remembered that I was supposed to help try building 2.0.11 this week. I'm so behind on my mental to-do lists... :( |
| # | 15:38:05 | Dyrcona | generic_ubuntu is still there. Now, it only does install_debs & debian_sys_configs |
| # | 15:38:43 | Dyrcona | I added some comments and a little white space for my (and others') sanity. |
| # | 15:39:27 | tsbere | sanity is overrated ;) |
| # | 15:45:39 | Dyrcona | just have to commit some changes, edit the README, rebase and I'll push to working. |
| # | 15:55:51 | Dyrcona | * [new branch] precise_pangolin -> collab/dyrcona/precise_pangolin |
| # | 16:23:17 | copystar has quit IRC |
| # | 16:25:59 | bwicksall has quit IRC |
| # | 16:28:45 | collum has quit IRC |
| # | 16:31:35 | phasefx | so, given the code here, http://paste.lisp.org/display/126365, I'd expect to get back a list of bre objects with the attrs field fleshed out (from metabib.record_attr, based on the IDL), but instead I get bah humbug. Am I doing something dumb? :) |
| # | 16:32:03 | phasefx | attrs is a virtual field, with a link to mra |
| # | 16:33:23 | phasefx | yeah, I'll just mimic what's going on with creator and editor |
| # | 16:33:28 | phasefx | forget flesh_fields |
| # | 16:33:40 | phasefx | thanks rubber duck channel |
| # | 16:34:05 | bwicksall has joined #evergreen |
| # | 16:50:36 | kmlussier has quit IRC |
| # | 16:54:47 | dbs has quit IRC |
| # | 17:04:35 | Shae has quit IRC |
| # | 17:07:01 | akilsdonk has quit IRC |
| # | 17:07:39 | dbs has joined #evergreen |
| # | 17:25:40 | jenny has left #evergreen |
| # | 17:28:37 | Dyrcona | Whee! I now have a functional dev machine on an Ubuntu 12.04 VM. |
| # | 17:28:47 | bshum | Dyrcona++ |
| # | 17:29:36 | Dyrcona | Time to go home. |
| # | 17:29:40 | Dyrcona has quit IRC |
| # | 18:11:02 | edoceo has left #evergreen |
| # | 18:37:44 | edoceo has joined #evergreen |
| # | 18:38:59 | edoceo has left #evergreen |
| # | 18:41:40 | edoceo has joined #evergreen |
| # | 18:43:23 | edoceo has joined #evergreen |
| # | 18:54:54 | edoceo has left #evergreen |
| # | 18:56:10 | edoceo has joined #evergreen |
| # | 19:00:32 | jenny has joined #evergreen |
| # | 19:00:34 | jenny has left #evergreen |
| # | 19:47:27 | StephenGWills has left #evergreen |
| # | 19:52:01 | dbs has quit IRC |
| # | 20:05:32 | dbs has joined #evergreen |
| # | 20:38:55 | pmpafk has quit IRC |
| # | 20:58:25 | edoceo has left #evergreen |
| # | 21:00:41 | edoceo has joined #evergreen |
| # | 21:00:51 | edoceo has left #evergreen |
| # | 21:01:58 | edoceo has joined #evergreen |
| # | 21:26:09 | dbs has quit IRC |
April 10-13