Evergreen ILS Website

IRC log for #evergreen, 2014-11-13

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
00:24 sbrylander joined #evergreen
00:42 sarabee joined #evergreen
03:45 sbrylander joined #evergreen
04:59 sarabee joined #evergreen
05:18 dreuther joined #evergreen
05:21 chatley joined #evergreen
06:35 Callender joined #evergreen
06:38 wsmoak joined #evergreen
06:38 wsmoak joined #evergreen
06:47 mnsri joined #evergreen
07:05 chatley_ joined #evergreen
07:05 dreuther joined #evergreen
08:00 rjackson-isl joined #evergreen
08:06 kmlussier joined #evergreen
08:09 kmlussier Oh well. Parts had nearly 4 hours of positive karma.  My job here is done. :)
08:09 kmlussier Good morning #evergreen!
08:11 akilsdonk joined #evergreen
08:14 phasefx joined #evergreen
08:14 Callender_ joined #evergreen
08:16 eeevil joined #evergreen
08:18 mtate joined #evergreen
08:19 graced joined #evergreen
08:24 collum joined #evergreen
08:25 TaraC joined #evergreen
08:31 * csharp reads yesterday's scrollback
08:32 mdriscoll1 joined #evergreen
08:36 * kmlussier wonders if there is something better than TwitterFeed to automatically post new items from the Planet Evergreen RSS feed to the Evergreen Twitter account.
08:36 kmlussier It's supposed to check the feed every half hour, but it still hasn't sent out yesterday's afternoon post regarding OPW
08:37 Shae joined #evergreen
08:37 mrpeters joined #evergreen
08:43 mmorgan joined #evergreen
08:44 csharp berick++ # RM
08:44 csharp kcls++ # sharing berick
08:45 csharp +1 to easier installation
08:45 csharp opw++
08:45 csharp okay, I think that catches me up
08:46 kmlussier csharp: Heh, it's fun watching you catch up
08:46 csharp :-D
08:46 ericar joined #evergreen
08:46 * csharp drove down to the soutwest tip of Georgia and back yesterday, so was utterly out of pocket
08:57 RoganH joined #evergreen
09:01 * wsmoak also thought that bit was interesting
09:02 wsmoak getting a dev environment running is a pretty big barrier to contribution…
09:02 csharp yeah
09:03 csharp btw, I'm one who would volunteer to help new devs get things up and running, for the record
09:03 wsmoak I don’t even know how much it would cost (or how it works) but what about some sort of image that runs on Amazon or Google’s  things?
09:04 wsmoak I’d be willing to pay for the server time (vs. running my own server here, which is probably what it would take…)
09:04 csharp you could definitely run a test server in the cloud, sure
09:04 wsmoak but I need my very own instance to break and then press a button and re-make
09:05 RoganH There are a couple of tools floating around for making VMs that you could do development on.
09:05 csharp you would need maybe 8 - 16 GB of storage, minimum 4 GB RAM, and 2 - 4 processor cords
09:05 csharp s/cords/cores/
09:05 mrpeters VM's and snapshots are the easy reset button :P
09:05 RoganH csharp: I thought you were going to break out into 80s power cords there for a minute.  :)
09:06 RoganH berick's scripts pop to mind which I've used
09:06 RoganH tsbere also has a method that I've heard good things about though I haven't tried it myself.  I know kmlussier uses it for building VMs for bug testing.
09:06 Stompro I really liked the Evergreen VM that used to be available.. but I realize that it takes a bit of work to keep it up to date.
09:07 wsmoak it needs to not be a separate thing that only new devs ever use … or it won’t get maintained
09:07 mrpeters yeah the vm thing never worked well
09:07 csharp RoganH: you mean like this? https://www.youtube.com/watch?feature=p​layer_detailpage&v=zpOULjyy-n8#t=90
09:07 RoganH it's too awkward to have a single community one for development, different needs run into each other too much
09:07 wsmoak or fix the underlying problem — installation/deployment should not be that hard
09:07 mrpeters i think the intent though is that they want new dev's to be capable of installing Evergreen themselves from the readme
09:08 RoganH csharp++
09:08 mrpeters wsmoak: what do you find most difficult about installation?
09:08 RoganH My wiki-fu is failing me but kmlussier linked both tools on the wiki somewhere.
09:11 wsmoak mrpeters:  really??? http://evergreen-ils.org/docume​ntation/install/README_2_7.html :)
09:11 Stompro RoganH: http://wiki.evergreen-ils.org/doku.php​?id=server_installation:semi_automated
09:12 RoganH Stompro++
09:12 mrpeters wsmoak: how is that different from installing anything else from source code though?
09:12 maryj joined #evergreen
09:12 wsmoak basically, I do not want to be a sysadmin.  I *can* do those things, I have done, but it’s not what I want to spend my time on these days.
09:12 RoganH Installing Evergreen really isn't that hard, it's just very time consuming and methodical, hence the tools to speed it up.
09:12 RoganH Note that these are for doing bug testing and development, not building a production environment.
09:12 mrpeters i'll give you time consuming for sure
09:13 mrpeters but, to fix bugs, you should be capable of installing OpenSRF/Evergreen
09:13 RoganH I agree.
09:13 mrpeters how are you going to fix something you break if you aren't able to do a scratch install, you know?
09:13 Stompro I hate editing the xml files... the fact that sometimes it's <password> and sometimes its <passwd>.  And dealing with all the ejabberd accounts.
09:14 mrpeters for me, personally, the solution to the time consuming bit is using VMWare (though Virtualbox would work fine too) and using snapshots
09:14 RoganH I was trying to point out tools that can help with blasting and rebuilding a test build of Evergreen, not saying that they void the need to have the underlying skills.
09:14 wsmoak :::shrug::: I don’t really want to fix bugs.  I want to play with it and write against the api and see how it all works and *then* maybe get more involved.
09:15 mrpeters no, I agree with you RoganH.  Once you can perform the install once, no need to repeat it over and over again (though, it does become like muscle memory to install Evergreen eventually haha)
09:15 RoganH using Virtual Box snapshots can work most of the time as well though I'd argue sometimes it's good to just be able to do a quick new build from git
09:16 mrpeters RoganH: true, only benefit to an "over the top" install from git is you don't have to screw with the config files
09:16 mrpeters really, if OpenSRF didn't change, i think all you'd need to do is run autoreconf -i and then make and make install
09:17 csharp wsmoak: if that's what you want, then build a stock 12.04 Ubuntu VM and install from GPLS's deb packages: http://archive.georgialibraries.org/
09:17 csharp that would certainly work on a cloud server
09:17 wsmoak csharp: thanks, will keep that in mind
09:18 Stompro csharp: I added info about the archinve.georgialibraires.org to the semi_automated page, it seems like if someone is looking for ways to automate the build, that should be included.
09:18 csharp Stompro++ # thanks
09:18 mrpeters csharp: maybe we should look into daily deb builds of master in another repo
09:18 mrpeters could become a bit of a monster daily, but maybe a weekly or monthly build
09:18 csharp not to re-hash recent discussions, but I'm puzzled as to why more new users *wouldn't* want to use our debs
09:19 RoganH csharp: I'll have to try out your packages, that looks convenient
09:19 wsmoak what I’m used to is something like: download .tar.gz, unpack, and run bin/start.sh
09:19 csharp they're about as close to stock as you can get
09:19 wsmoak (because I’m on OSX)
09:19 mrpeters would keep us on our toes and lessen the changes we have to make when we build new versions of the debs because we're following master more closely
09:20 wsmoak embed a “lite’ database of some kind that it can use internally, and Just Work.
09:20 csharp wsmoak: well, if you can run VirtualBox on your Mac and build an ubuntu server guest, just follow the instructions at the archive.georgialibraries.org site and you'll be up and running within minutes
09:21 wsmoak … but that leans a lot on Java’s built-in stuff I know, with the ability to swap out data sources easily
09:21 RoganH If you're running OSX virtual box is your friend.
09:21 mrpeters heck yeah it is
09:21 csharp wsmoak: we do have a test dataset (not automatically installed by the .deb package, fwiw)
09:21 RoganH You can pay for VMWare (I used to) but Virtual Box has gotten so good in the last few years.
09:22 mrpeters when i was at ISL my "master" server for submitting new patches, development, etc. was just a virtualbox VM on their OS X server
09:22 mrpeters csharp: we could make the test data load SO easy.  There is a flag now for eg_db_config to load all of that
09:22 mrpeters i discovered it monday
09:23 mrpeters --load_all_test or something
09:23 mrpeters we could add that to our debs pretty easily i think
09:23 csharp yep
09:24 mrpeters maybe have it set up so you can do an apt-get install evergreen-ils and apt-get install evergreen-ils-populateddb
09:24 csharp I wonder if it should be a separate deb, though
09:24 mrpeters ^^ great minds :)
09:24 csharp right
09:25 mrpeters but i am 100% in agreement with whoever yesterday was saying that you should at least do the install once or twice.  If you can't, you'll struggle to fix things as you are developing code.
09:28 wsmoak I agree … but it shouldn’t have to be the *first* thing you have to do as you begin to get involved
09:29 wsmoak but it depends on the kind of contributors you are trying to attract, too
09:29 RoganH Part of the history of the Evergreen community is that the vast majority of the developers have been sysadmins too so the two have been interlinked.
09:32 kmlussier RoganH: I posted links to berick's install script and tsbere's VM builder on the OPW page in the "Learning About Evergreen" section. http://wiki.evergreen-ils.org/doku.php?id=opw
09:33 RoganH kmlussier: that's why I couldn't find it, I was looking at the bug squashing stuff.  baka no rogan
09:36 jeff bshum, gmcharlt, other web folk: passing along some feedback from jcoyne in #code4lib regarding the downloads page (paraphrasing): it would be nice to have the git:// url of the repository near the gitweb link. as it stands now, the git:// repo url needs to either be guessed/inferred or you need to click another link from the gitweb branch display
09:37 jwoodard joined #evergreen
09:37 yboston joined #evergreen
09:37 mrpeters jeff: the clone URL you mean?
09:38 jeff right -- the url to the repo / remote as opposed to the url to the gitweb display. git://git.evergreen-ils.org/Evergreen.git
09:38 mrpeters yeah, good point.  its on http://git.evergreen-ils.org​/?p=Evergreen.git;a=summary right at the top, but probably wouldnt hurt to add to whichever static page he means on evergreen-ils.org
09:39 mrpeters did he mention exactly which page he meant by the "downloads" page?
09:39 mrpeters i guess /egdownloads does have the git repo links
09:39 mrpeters but, i dont know that you can "clone" just one tag, can you?
09:40 mrpeters i think thats what we link to now
09:40 bshum There are ways to do it, I'm sure.
09:40 mrpeters maybe we could change that to "Git Tag | Git Clone URL"
09:40 bshum Indeed.
09:41 mrpeters http://git.evergreen-ils.org/?p=Evergre​en.git;a=shortlog;h=refs/heads/rel_2_7 |   git://git.evergreen-ils.org/Evergreen.git
09:41 bshum What I might suggest is another row (gah) for that then
09:41 bshum I *like* the gitweb view of all the commits
09:41 mrpeters me too
09:41 kmlussier me three
09:41 mrpeters what about a footnote in smaller print below that that gives the clone url in plain text
09:41 mrpeters because a "link" won't do you much good if what you need to do is git clone  git://git.evergreen-ils.org/Evergreen.git
09:42 * kmlussier wonders how this might fit into the new downloads page graced and I are supposed to be working on.
09:42 bshum Well I could see a git link being handy if one had a tool installed on their system to follow those links
09:42 jeff right. either specify the url elsewhere on the page and specify the git branch, or specify the git url and the branch next to each other for each release, or just have a link on the downloads page to a "git details" page... many many options.
09:42 bshum No?
09:42 mrpeters true, i think Windows may have some tools that would handle git:// protocols, not sure on Linux
09:42 * graced feels guilty for not getting to that with kmlussier
09:42 jeff mrpeters: all of this suggestion is link as text to copy, not a clickable link.
09:44 mrpeters jeff++
09:44 mrpeters let me mock something up real quick
09:46 jboyer-isl The reason a link might be better than plaintext, even without a git:// url handler, is that many (all?) browsers have a right-click "Copy URL" or link, etc. that's one less thing to do (selecting only the text of the url).
09:46 bshum Maybe what we should do is to add a new section
09:46 bshum "How to clone Evergreen" or whatnot
09:47 bshum And put the link in there
09:47 bshum Along with links to the dev:git page
09:47 jboyer-isl It doesn't have to be called out very much, most people will want the downloads. The people who care about the clone url will recognize it.
09:47 bshum And change the name of the row to "Git Summary" or something instead of Repository
09:47 bshum The more I read, the more I think the git URL will be the same
09:48 bshum But we have to specify something like how to check out a specific branch?
09:48 bshum Since it'll clone the same repo, but you can choose which branch to view a particular series.
09:48 mrpeters http://i.imgur.com/kK3bWLP.jpg --- my idea
09:48 bshum Or maybe I'm missing something in my reading so far for git urls
09:49 mrpeters oooh here we go
09:49 mrpeters git clone -b mybranch --single-branch git://sub.domain.com/repo.git
09:49 jeff jboyer-isl: there's also the style that many sites use where you click the text and it's all hilighted or copied to your clipboard or there's a small button to copy to your clipboard, etc. github, bitbucket, etc.
09:49 kmlussier I think it would be better to link to the existing git page for instructions rather than providing instruction on the downloads page.
09:49 mrpeters that is also not a bad idea
09:49 bshum mrpeters: aha
09:50 mrpeters i guess if you know what "Git" is though, you probably will understand what to do with the clone URL
09:50 mrpeters (is that still considered a URL?)
09:51 jeff kmlussier: yep, i'm leaning toward that as well. perhaps a hybrid approach of having the git clone url on the downloads page with a "more git info" link that takes you to an existing or new page regarding how we use git (evergreen-specific things you should know, etc)
10:00 jboyer-isl mrpeters, Probably a URI if you want to be picky, I can never remember the difference
10:00 mrpeters heh yeah
10:03 Stompro Does anyone have a "New Patron Welcome Email" notice that they use?  We currently try to email a new customer right away, so that if their email is bad the staff have a chance to fix it while the customer might still be in the building.  I just need to figure out if that is possible with action triggers.
10:04 mrpeters so, if gpls were to host a deb of the current "stable" release with and without test data would the community advertise that as a "quick start" or would that still meet resistance because it doesn't account for installing the software, and could **potentially** cause someone to accidentally upgrade the package when they didn't intend to
10:06 Stompro mrpeters: I'm pretty new, but I would support that and I would help add it to the community install docs.
10:06 kmlussier berick++
10:07 Stompro mrpeters: would it be Ubuntu only or could Wheezy and Jessie users make use of it?
10:07 kmlussier Stompro: I looked into it once, but didn't get very far. That's not to say it isn't doable. I just don't have a good handle on action triggers.
10:08 kmlussier I think it's a fabulous idea!
10:08 mrpeters we would have to build seperate debs for those, i think
10:08 mrpeters debian has some slightly different install steps
10:08 bshum mrpeters: I think that's an interesting offer.  Though I'm always curious to see the deb building process you guys have come up with in action.
10:08 mrpeters I could make a demo video
10:09 mrpeters i just hate hearing my own voice narrate it....and today is NOT the day to do that....60 degrees to 22 degrees in 12 hours did not help my throat
10:11 mrpeters there is a little work done (Andy Witter usually handles it) to build any new debs for things that would normally get installed from source (spidermonkey, etc.) but if those don't change much from version to version, its really just grab the tarball and put it in a certain location and then run a script
10:11 mrpeters you can pick "cluster" or "single server"
10:11 mrpeters for the repo, its single server
10:12 mrpeters only half of that I don't have a lot of knowledge on yet is the actual apt archive
10:12 mrpeters not sure where Andy sticks the built debs up to update the repo
10:13 mrpeters i just tell him hey, i built the 2.7.1a debs can you update the repo and link him my deb
10:14 mrpeters one thing that would be cool, and im not sure if it could be done, is to have ALL of the old debs still there too, so you could do say, apt-get install evergreen-ils-2.0.4 and get the 2.0.4 build installed
10:14 mrpeters wouldn't see many reasons to do that, other than nostalgia or testing "did this act differently before?" but could be handy
10:17 bshum With deb files, wouldn't the version be part of the package name though?
10:17 bshum Usually
10:18 mrpeters yeah, i think traditionally it is
10:18 mrpeters since we just keep only the latest deb on the server, its just generic evergreen-ils
10:18 mrpeters and archive.georgialibraries.org lets you know which version
10:37 mrpeters Stompro: im sorry, i started answering your question about a new patron email and forgot to finish :P
10:37 mrpeters I think it would be possible.  I'm not sure if there is a reactor available yet for "New Patron Created" (I could be wrong though) but I think you could pull this off
10:38 mrpeters i had an A/T event that ran when a patron's account expired in 30 days (the bad side effect was it only ran once) so if a patron expired a second time, no email!
10:38 mrpeters but that would be ok in this case
10:38 mrpeters wondering if we might adapt that to what you need
10:43 Stompro Yes, that could work, just set to our normal expiration date, -3 Years with no repeat_delay set.  I wonder if there is anything that can target email address changes also?
10:43 mrpeters oh, did i misread?  i thought you only wanted to email a customer when they were newly registered
10:46 Stompro Nope, Just thinking the process through.  Right now I just look for new accounts and send one email, but ideally I would want to send a new email if it turns out that the initial email is invalid.  It might make sense to send a confirmation email any time an email gets changed.
10:47 mrpeters ah, i see
10:47 mrpeters but you would benefit from an A/T event definition that sends an email when a new actor.usr is created (provided they have an email address in the registration)
10:48 mrpeters I think most of the infrastructure is there for something like that, only thing im not sure about is the reactor for a new row in actor.usr
10:49 Stompro Yes, we would use that.  And I bet some locations would also like to send postal mail to new customers also, to confirm new mailing addresses and to send out welcome packets.  We have toyed with that idea.  So it would probably be useful in general.
10:49 mrpeters Yeah, i think that is an excellent justification to file a wishlist bug
10:50 mrpeters you have several clear uses for it that i think lots of libraries would be interested in
10:50 akilsdonk joined #evergreen
10:51 Stompro mrpeters++ thanks for the ideas.
10:52 Stompro I'll submit a wishlist bug.
10:52 mllewellyn joined #evergreen
10:52 mrpeters awesome.  i think that could be a really cool feature.
10:56 jboyer-isl joined #evergreen
10:56 rjackson-isl joined #evergreen
10:56 nhilton joined #evergreen
10:57 rjackson_isl joined #evergreen
10:59 * phasefx_ tweaked the wheezy installer link on the semi_automated page to point to a README
11:17 sarabee joined #evergreen
11:22 jboyer-isl joined #evergreen
11:23 rjackson-isl joined #evergreen
11:44 Stompro mrpeters: Bug 1392396 - Should i be using the blueprint feature for something like this in the future?
11:44 pinesol_green Launchpad bug 1392396 in Evergreen "Wishlist: Action Trigger for new user creation" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1392396
11:45 mrpeters hmm not sure, i haven't used it before
11:45 mrpeters loooks good though
11:47 kmlussier Stompro: The community very rarely uses the blueprint feature. I think it would be just as good to outline what you propose right on the LP bug.
11:49 sandbergja joined #evergreen
11:55 * dbs concurs with kmlussier++
11:59 csharp @dunno add Sorry, we can't do that because, you know, SOFTWARE.
11:59 pinesol_green csharp: The operation succeeded.  Dunno #34 added.
12:00 kmlussier csharp++
12:02 bshum kmlussier++ # good advice on transcendent bibs vs. $9 CONS asset.uri's
12:02 Callender_ joined #evergreen
12:25 jboyer-isl kmlussier, bshum, where might this advice be found? I'd like to have a look-see.
12:26 kmlussier jboyer-isl: In a private message exchange? :)
12:26 jboyer-isl (though now it's time to head AFK and to the DC. :-( / :-D  )
12:26 kmlussier I was just suggesting that bshum change some bibs with a transcendent big source to use located URI's at the top of the org tree.
12:26 bshum I was just musing on how transcendent bibs don't show up as links in the search results. And she suggested using $9 CONS to make them visible consortially and bypass that.
12:27 jboyer-isl Oh, ok. I thought it was more about visibility differences. OK.
12:27 kmlussier But the other benefit of the located URI approach is that they won't show up in copy location limited searches, which can sometimes be weird.
12:27 ericar joined #evergreen
12:27 jboyer-isl That was one of my concerns when we were loading more trancendent records.
12:27 * jboyer-isl vanishes.
12:28 kmlussier For example, if somebody limits a search to children's copy locations and finds a copy of the karma sutra from Project Gutenberg.
12:36 tsbere Making transcendent records not show up with copy location searches would be easy, BTW. <_<
12:37 * tsbere isn't sure if it is a good idea or not, though
12:37 kmlussier Adding a subfield 9 at the top of the org tree is also easy. :)
12:37 tsbere kmlussier: Unless you have the option to scope URIs like Copies turned on. Then things become harder.
12:39 kmlussier How so? I always found the scoping for located URI's to work fairly well for consortium-wide resources. The "scope URIs like copies" helped with resources owned by ou's lower down in the org tree.
12:40 tsbere kmlussier: If you turn the URIs like copies option on then "top of the org tree" URIs only show up when searching from the top of the org tree. Limit yourself to anything lower and as far as I know they would stop showing up.
12:40 kmlussier No, that's wrong
12:43 tsbere kmlussier: I would argue then that the setting is horribly mis-named, then, because it isn't acting like a copy.
12:44 * kmlussier notes that all of the examples in the docs at http://docs.evergreen-ils.org/2.7/_cata​loging_electronic_resources_8201_8212_8​201_finding_them_in_catalog_searches.ht​ml#_adding_a_located_uri_to_the_record were working as described back in the summer.
12:44 jeff are they no longer working as described?
12:44 kmlussier tsbere: If the subfield 9 is set to the consortium without the setting enabled, then it will show up in searches all the way down the org tree. But if it's set at a system or branch level, it only travels down, not up.
12:45 kmlussier jeff: I believe they are. I haven't tested it since then.
12:45 kmlussier tsbere: If you enable the setting, then the resource shows up both up and down the org tree. So if it's owned by a system and you search the consortium, it still shows up. Like copies do.
12:45 tsbere kmlussier: As far as I know, copies only travel "up", not "down", so if the setting makes them travel *both* ways then URIs aren't acting as copies.
12:46 tsbere kmlussier: Which would make the setting's name horribly wrong. :P
12:46 kmlussier tsbere: If your search is scoped to the consortium, you don't see copies owned by a branch?
12:47 tsbere kmlussier: If my search is scoped to a sublibrary I don't see copies owned by the main library it is under, but the main library search would include the sublibrary. The same two searched without the "uris as copies" setting active would show the main library URIs when searching the sublibrary but not the sublibrary URIs when searching the main library.
12:48 tsbere If the uris as copies option is turned on and doing what you say then they are not acting as copies as they are scoping *both* ways and copies only scope *one* way.
12:50 kmlussier tsbere: You're right. But what you said above is that if the consortium were located in subfield 9, it wouldn't show up in searches that are limited further down the org tree.  But they do, regardless of the state of that setting.
12:50 tsbere kmlussier: And on that front, the label for the setting is "When enabled, Located URIs will provide visiblity behavior identical to copies." < Scoping *both* directions is *not* identical to copies. As such, I would call that a bug.
12:51 kmlussier I think a big difference is that, except in cases like the sub-library example, ou's higher up the org tree do not own copies, whereas they do for electronic resources.
12:51 tsbere kmlussier: Whether or not we *want* located URIs to scope both directions (with option or otherwise) is a different issue. As it stands, there is currently no way to make them act identically to copies, despite the option saying that is what it does. :p
12:52 jeff i find myself curious how a copy behaves when you DO associate it with a circ_lib of the top-of-tree :-)
12:52 kmlussier jeff: The same question just occurred to me. :)
12:52 tsbere jeff: I seem to recall it only shows up when scoped to the top of the tree.
12:52 * tsbere has done stuff like that before
12:54 kmlussier I guess the specific name of the settings was used to show how enabling it differs from default behavior. The default behavior is what makes the electronic resource show up in searches higher up the org tree. Enabling the settings is what allows it to travel down, as copies do.
12:56 tsbere kmlussier: My (current) point being that the name and description *don't match what it does* - Copies by default travel "up" the tree, URIs by default travel "down" the tree, that option tells URIs to travel "up AND down" the tree. That is not acting like copies. That is acting like a combination of copies and URIs at the same time.
12:58 * tsbere is assuming that kmlussier's assertion about things is true, BTW, and has not tested or dug the actual code up at this point
13:00 dbwells I agree with tsbere that the setting doesn't really do what it claims.  Anyone interested in all the various cans of worms should check out ldw's bug #1353643.  I suspect the fallout from that will clarify the original setting as well.
13:00 pinesol_green Launchpad bug 1353643 in Evergreen "URI $9 displayes too many links in TPAC" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1353643
13:05 * eeevil is running to a doctor's appointment (already late) but the setting is to make URIs act like copies /in that/ they scope "down". it doesn't remove the "up" scoping, though. electronic resource limiting is about modeling access rights, where the uri owner (and it's subordinates) should have access
13:06 eeevil so, maybe the description for the setting should be "make uris act more like copies, but not exactly, because they're different things"
13:06 * tsbere wishes we could decide which way is up and which way is down when talking about this
13:07 kmlussier +1 to eeevil's suggested wording.
13:07 nhilton joined #evergreen
13:07 tsbere Perhaps something like "When enabled, Located URIs will provide visiblity behavior similar to copies in addition to their normal visibility behavior."
13:11 kmlussier The thought that occurred to me while writing the documentation re-occurs to me now. The name of that setting is unusually long. Makes for awkward wording in the docs.
13:11 * kmlussier doesn't have a suggestion for better wording.
13:13 Callender_ joined #evergreen
13:15 nhilton_ joined #evergreen
13:19 nhilton joined #evergreen
13:20 ericar joined #evergreen
13:21 tsbere kmlussier: The name is unusually long?
13:22 ericar_ joined #evergreen
13:22 tsbere kmlussier: The name is one of the shorter ones. The label isn't unusually long either, all things considered.
13:23 tsbere opac.browse.holdings_visibility_test_limit is the longest name (42 chars) and opac.use_autosuggest has the longest label (212 chars)
13:25 jihpringle joined #evergreen
13:25 kmlussier tsbere: Label. You have to remember, I tend to speak like an end user. Sorry for the confusion.
13:28 mdriscoll1 left #evergreen
13:30 mdriscoll joined #evergreen
13:32 hbrennan joined #evergreen
13:35 wsmoak left #evergreen
13:37 kakes joined #evergreen
13:40 pinesol_green [evergreen|Fredric T Parks] LP#1246839: marc_stream_importer.pl no longer crashes with vs 0.23 of File::Temp - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=a10f881>
13:50 Christineb joined #evergreen
13:50 remingtron2 joined #evergreen
13:54 susie joined #evergreen
13:55 kmlussier Heads up. Evergreen for Academics meeting starts here in 5 minutes.
13:56 pinesol_green [evergreen|Kathy Lussier] Add KPAC configuration info to the community docs - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=93c850b>
13:56 pinesol_green [evergreen|Josh Stompro] LP#1116387 - adding kpac setup notes. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=c1b9fa3>
13:56 pinesol_green [evergreen|Josh Stompro] LP#1083639 - Added command to copy fonts into the KPAC2 / Alternate monster skin dir - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=4da8069>
13:56 pinesol_green [evergreen|Galen Charlton] LP#1083639: use "cp -r" instead of "cp -R" - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=95b4cd6>
13:56 tspindler joined #evergreen
13:57 kmlussier Wow - that's an old one
14:00 kmlussier #startmeeting 2014-11-13 - Evergreen for Academics meeting
14:00 pinesol_green Meeting started Thu Nov 13 14:00:20 2014 US/Eastern.  The chair is kmlussier. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00 pinesol_green Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00 pinesol_green The meeting name has been set to '2014_11_13___evergreen_for_academics_meeting'
14:00 kmlussier #info Meeting agenda is available at http://evergreen-ils.org/dokuwiki/doku.p​hp?id=evergreen_for_academics:2014-11-13
14:00 kmlussier #topic Introductions
14:01 kmlussier Please introduce yourselves with the #info command.
14:01 kmlussier #info kmlussier is Kathy Lussier, MassLNC
14:01 mdriscoll #info mdriscoll is Martha Driscoll, NOBLE
14:01 kakes #info kakes is Kelly Drake, FLO
14:01 tspindler #info tspindler is Tim Spindler, C/W MARS
14:02 yboston #info yboston - Yamil suarez, Berklee College of Music
14:02 Christineb #info Christineb is Christine Burns BC Libraries Cooperative
14:03 kmlussier Rather than going through the past action items, which are very similar to the new business items, I think we can dive into each subgroup area to see where we're at.
14:04 kmlussier #topic Academic PAC flavor
14:04 kmlussier yboston: Can I hand over the updating to you on this one?
14:04 yboston sure
14:04 yboston I don't hvae  an update for the PAC flovor group, except...
14:05 yboston that I put together a wiki page from the main Evergreen for academics page
14:05 yboston http://evergreen-ils.org/dokuwiki/doku.php?id​=evergreen_for_academics:pac_academic_flavor
14:05 yboston #link http://evergreen-ils.org/dokuwiki/doku.php?id​=evergreen_for_academics:pac_academic_flavor
14:06 yboston going forward I can send out an email to solicit comments on how this group wants to proceed
14:06 yboston any comments so far?
14:06 yboston kmlussier: feel free to make an action item for me
14:07 kakes looks good, I'm surprised DanB hasn't commented
14:07 kmlussier I think one thing we need to do is look at the suggestions that have already been made and figure out which ones are truly academic issues and which ones should be LP bugs/feature requests for the overall catalog.
14:07 yboston makes sense
14:08 pinesol_green [evergreen|Jason Stephenson] LP#1246371: Allow BibCommon::title_is_empty to accept a bre id or bre object. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=984b402>
14:08 Callender_ joined #evergreen
14:08 yboston would you like me to pull that data together? maybe you can send the follow up email for the group?
14:08 yboston or viceversa?
14:08 kmlussier In my mind, the one that might play into academic flavor is perhaps a view with more fields displaying. Everything else seems to be general catalog issues.
14:09 kmlussier yboston: No, we can start with your email soliciting general comments.
14:09 yboston OK,
14:10 kmlussier #action yboston to send email to list on how to proceed with academic flavor ideas.
14:10 kmlussier Does anybody else want to add anything on the academic flavor topic? Or throw out some ideas now on what we should be doing here?
14:11 kmlussier #topic Batch Patron Functions
14:11 kmlussier #link http://evergreen-ils.org/dokuwiki/doku.php?id=​evergreen_for_academics:batch_patron_functions
14:11 kmlussier I know mdriscoll has done a bit of work on this.
14:11 akilsdonk_ joined #evergreen
14:11 mdriscoll Yes, those are my notes based on lots of patron loads
14:12 mdriscoll I tried to include all the issues I run into when loading files
14:13 mdriscoll I would also like to see batch patron update and delete functionality.
14:13 yboston mdriscoll++
14:13 jck_ joined #evergreen
14:13 mdriscoll I know the database has patron buckets but no front-end to use them
14:13 tspindler batch update and delete would be great
14:13 kmlussier So those look like they could potentially be two different projects.
14:13 mdriscoll They would probably be two different interfaces, so two different projects makes sense
14:14 kmlussier mdriscoll: I'm thinking batch loading of patron records may run into similar issues as batch loading records. Maybe I'll look at some of the issues we've run across there to see if any may be things we should be thinking about for these requirements.
14:15 mdriscoll Sounds good.
14:15 DonB joined #evergreen
14:16 kmlussier Does anyone have any specific comments or suggestions for these projects right now?
14:16 kmlussier If not, I think this would also be a good one to share via the list for feedback. But they look really good to me.
14:16 pinesol_green [evergreen|Josh Stompro] LP#1384932: document the zips.txt ZIP code database feature - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=66544eb>
14:16 kmlussier mdriscoll++
14:16 tspindler on the patron load, i think having good reporting on matches etc. would be good
14:17 mdriscoll tspindler: agreed.  I'm thinking of the vandelay interface where you can view every match.
14:17 tspindler mdriscoll has a lot down though
14:17 mrpeters joined #evergreen
14:18 mdriscoll kmlussier: should I send a message to the general list looking for feedback?
14:18 kmlussier It might also be good to identify a minimum number of records you expect the loading interface to handle.
14:18 tspindler kmlussier++
14:18 * kmlussier doesn't know what this number should be, but she knows this is a big issue with bib record loading.
14:19 mdriscoll Good idea.
14:19 kmlussier mdriscoll: Yes, I'll put you down for an action item.
14:19 mdriscoll I load 1000 records at a time but do see a hit on the db
14:19 tspindler in our network it is probably 5000
14:19 tspindler we have community colleges that have that many
14:19 mdriscoll That's why I put "don't impact running system" in the specs
14:20 mdriscoll Nobody cares if the load slows down, but users care if the db slows down.  It should not timeout either.
14:20 kmlussier #action mdriscoll to send message to Evergreen list to get feedback on requirements for batch patron load and for batch batch patron updates/deletes through patron buckets
14:20 tspindler mdriscoll++
14:20 kmlussier Thanks Martha! They look good. :)
14:21 kmlussier Anything else on patron batches?
14:21 kmlussier #topic Authorities
14:22 kmlussier We have a link at http://evergreen-ils.org/doku​wiki/doku.php?id=authorities, but I think that's the pre-existing authorities page, right?
14:22 tspindler First, I'm going to have to step down since I will have change in responsibilities starting January 1
14:22 kmlussier tspindler: Congrats, by the way! :)
14:22 mdriscoll tspindler: congrats!
14:22 yboston what is the new position?
14:22 tspindler I start as executive director
14:22 yboston Cool
14:22 Stompro joined #evergreen
14:23 tspindler I looked at yboston page closely and he has a lot of detail on there
14:23 kmlussier tspindler++
14:23 tspindler i think it is a good start
14:23 tspindler btw, jkranich will continue to participate here with the academics for us
14:23 kmlussier I just want to note that there is some work being done on overlaying authorities via Vandelay.
14:24 kmlussier Or, I should say, it looks like there is work being done.
14:24 kakes yboston: it's a great start, very good list
14:24 yboston BTW, I have been working with EG authorities for a while and could lead the group, but oly if someoe else takes over the LC group
14:24 yboston *only
14:24 kmlussier bug 1171984
14:24 pinesol_green Launchpad bug 1171984 in Evergreen "add support in Vandelay for overlaying authorities during import using match sets" (affected: 4, heat: 18) [Wishlist,Triaged] https://launchpad.net/bugs/1171984 - Assigned to Liam Whalen (whalen-ld)
14:24 kakes kmlussier: who do you think is working on the overlay?
14:25 kmlussier Are there still issues for the LC Call number group once dbwells's code is tested and merged?
14:25 Stompro gmcharlt: Thanks for reviewing and committing the KPAC setup docs. gmcharlt++
14:25 kmlussier Sorry, that's the next agenda item. I withdraw the question.
14:25 dbs #info dbs = Dan Scott, Laurentian University (with coffee in hand, finally)
14:25 kmlussier kakes: It looks like berick has been working on it.
14:25 kmlussier dbs: Welcome! I'm glad you have coffee. :)
14:26 kmlussier MassLNC has also been talking to ESI to get some tweaking done for the browse authority work.
14:27 kmlussier Other than yboston, is there anyone else who is willing to take over the authorities group? If not, is there somebody who can take over the LC Call Number group (if needed) so that yboston can focus on authorities?
14:29 kmlussier yboston: Which area do you prefer to work on?
14:29 yboston I think my co-workers would prefer I focus on authoritites
14:29 yboston so we can move me to authorities for now, and look for a new volunteer for LC callnumbers later on
14:30 kmlussier OK, then, I'm inclined to say you should lead that group and we'll deal with the other group in a minute.
14:30 DonB #info DonB = Don Butterworth, Asbury Seminary. Was on the phone with YBP (Yankee Book Peddler). Evergreen EDI does *not* work with YBP. Another Academic issue for us.
14:30 yboston I sitll have a smalll report for call numbers today
14:30 kmlussier #action yboston to take charge of the authorities group.
14:30 kmlussier I think authorities is a big area to tackle.
14:30 DonB What would be involved in leading LC callnumber. I might be able to take that on.
14:31 tspindler i think yboston has some of the biggest issues on the wiki page
14:31 kmlussier Hold on a second. Anything else on authorities?
14:31 kmlussier #topic Call Number Sorting
14:32 kmlussier yboston: Can you start us with an update?
14:32 yboston yes
14:32 yboston I finally put in a bug for issues searching LC calnumbers in OPAC numeric searches; bug 1389403
14:32 pinesol_green Launchpad bug 1389403 in Evergreen "OPAC numeric search's call number search bug with LC call numbers " (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1389403
14:32 yboston I then added a link inside the bug to some test code that Dan Wells wrote to address the issue. I saw that Kathy tried testing that code during the EG bug squashing day.
14:32 yboston I still need to query the community to see what other LC call number issues need to be addressed
14:33 kmlussier I still owe a response to dbwells regarding what we're seeing in the logs.
14:33 yboston and I made a basic wiki page for this group too
14:33 kmlussier I think I sent out a query to the Evergreen community.
14:33 yboston #link http://evergreen-ils.org/dokuwiki/doku.php?id=e​vergreen_for_academics:improved_lc_call_number
14:33 yboston kmlussier: yes, you sent out an email, and I might have beent he only one that replied at the time?
14:33 kmlussier #link http://georgialibraries.markma​il.org/thread/wwdb2nrn4g4sunbb
14:34 kmlussier I didn't get any other responses. Are there other issues you all have seen with LC Call number other than what was identified in the bug yboston just posted?
14:35 kmlussier Because if that code fixes all of the LC issues that are out there, I don't think this sub-group is needed.
14:36 kmlussier Sorry. There is also the issue with spine label printing that DonB identified in bug 1352542.
14:36 pinesol_green Launchpad bug 1352542 in Evergreen "Printing: LC Call number formatting (2.5.2)" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1352542
14:37 dbs dbwells: are we normalizing the incoming call number label? /me isn't seeing that immediately in supercat
14:38 remingtron dbwells is in a meeting at the moment
14:38 yboston since we have one definite open bug, and one bug that has a fix awaiting more testing, we can keep the group open for now
14:38 kmlussier DonB: Since you semi-volunteered up above, is this something you want to work through. At this time, I'm thinking it's primarily about identifying specific issues that are still out there.
14:39 yboston I am sure there are other bugs I could report if I talk to the cataloger here, though she is on maternity leave right now
14:39 * dbs sees that that's what the patch from dbwells is trying to do; seems reasonable
14:40 DonB I'm willing to try to identify LC Call number issues and report back to the group, if that would be helpful
14:40 kmlussier DonB: Yes, that would be very helpful. Thanks!
14:40 kmlussier :)
14:40 yboston DonB: that would help, also if you can add info tot he wiki page too
14:40 kmlussier #action DonB to identify remaining LC Call Number issues and report back to the group.
14:41 yboston I can help train you on using the wiki
14:41 kmlussier Anything else on LC call numbers?
14:41 DonB Willing to try. Thanks for being willing to teach the new guy
14:42 yboston shoudl we set an action for you to give feedbacl to Dan? Don't think it is neccesary, just wondering
14:42 kmlussier DonB: We like new people, so we're always willing to help the new guy. :)
14:42 pinesol_green [evergreen|alzr] LP#1207529: Make sure $PATH includes /openils/bin when configuring - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=85f3866>
14:42 pinesol_green [evergreen|alzr] LP#1207529: Add /openils assumption note - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=e38ec30>
14:42 yboston you being Kathy
14:42 yboston we were all new like you once
14:43 kmlussier #action kmlussier to post testing feedback for dbwells on bug 1389403
14:43 pinesol_green Launchpad bug 1389403 in Evergreen "OPAC numeric search's call number search bug with LC call numbers " (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1389403
14:43 kmlussier Got it.
14:43 kmlussier Those are all the sub-groups then.
14:43 kmlussier Is there anything else anybody wants to bring up?
14:44 DonB Does anybody else care about EDI working with YBP
14:44 DonB ?
14:44 DonB It is a major player with academic vendors
14:45 tspindler DonB: we have academics that use them but do not use EG acquisitions
14:45 DonB And it frustrates me that the parent company Baker and Taylor has a working EDI with Evergreen
14:45 DonB but not YBP
14:45 tspindler YBP does noting with EDI?
14:45 DonB It worked well with our legacy system
14:45 kmlussier Is it just the invoicing/enriched EDI, or is it the ordering too?
14:45 DonB Ordering
14:46 dbs Is YBP specifically academic? /me really doesn't know
14:46 DonB They are starting to lose my business because of all the hoops they make me jump through
14:46 DonB Sorry. Maybe I'm just venting
14:46 tspindler dbs: not sure but in my experience, i have only known academics to use them
14:47 gmcharlt ditto
14:47 kmlussier I think there are probably a number of vendors that EDI still doesn't support, but, with each of them, some development needs to be done to get Evergreen talking to them.
14:48 kmlussier But it doesn't sound like there are many people in the channel right now who use them heavily and use EDI. Maybe it's a good question for the lsit.
14:48 kmlussier s/lsit/list
14:48 tspindler i was just talking to one of our staff, he worked for YPB and he said they were working to get set up with evergreen at the time about 3 years ago
14:48 kmlussier If there are a few sites interested in it, it might be a good opportunity to pool funds to get the development done.
14:49 DonB We need more academic libraries so we can get a mass critical enough to interest vendors like YBP and Harrassowitz
14:50 kmlussier DonB: But is the problem that YBP is unwilling to work with Evergreen or that nobody on the Evergreen side of things has tried to get it to work with YBP?
14:50 DonB kmlussier: We have tried to get it to work without success
14:50 jihpringle we don't use YBP but I know we had to do some tweaking of the PO JEDI action trigger and the EDI fetcher/pusher to get Evergreen to work with the major Canadian public library vendors
14:51 tspindler DonB: have you got it working with others?
14:51 DonB kmlussier: It works with Baker & Taylor
14:52 kmlussier I think a good start might be to query the list to see which other sites out there need EDI working with YBP. And then maybe you can, as a mass, try to get YBP to work with Evergreen.
14:53 * mdriscoll runs off to another meeting
14:53 kmlussier DonB: Does that sound like a good approach?
14:53 DonB Might make for a good survey question.
14:53 kmlussier Thanks for joining us mdriscoll!
14:53 DonB What vendors do you use? and Who uses EDI?
14:54 jihpringle we'd be interested in the results of that survey
14:54 kmlussier I know a lot of our libraries use B&T, Ingram, Midwest Tape. tspindler may know of more.
14:55 kmlussier What exactly would be the goal of the survey then? To see what vendors we want to see working with EDI?
14:56 kmlussier If so, is anyone willing to create this survey?
14:56 DonB Just to see how many libraries use EDI
14:56 DonB and
14:56 DonB How many would like to use EDI
14:56 DonB and
14:56 DonB Who would they like to use if they could
14:57 jihpringle the end result would also be a list of known vendors that work with Evergreen's EDI
14:57 kmlussier I think the survey is fine. But I think we're not stepping outside of the purely academic realm. Because all types of libraries use EDI.
14:57 DonB Then perhaps we could use the results to get some vendors working on making the connections work with Evergreen
14:58 DonB You're right Kathy
14:58 kmlussier We're closely approaching the one-hour mark. Does anyone want to take this as an action item?
14:58 DonB Maybe we could put this on the back burner as another academic library topic to address at a later date?
14:58 tspindler kmlussier:  we have librairies currently using only B&T, Ingram and Midwest Tape.  We have not tried others.
14:59 kmlussier Sure, that works for me.
14:59 tspindler at lest with EDI.  We have some tracking manual orders
14:59 kmlussier Anything else before I wind things up?
14:59 kmlussier Our next meeting is scheduled for 2 p.m. EST on December 11.
15:00 kmlussier #info Our next meeting is scheduled for 2 p.m. EST on December 11.
15:00 kmlussier #info Add an EDI survey as a future to-do item.
15:00 kmlussier #endmeeting
15:00 pinesol_green Meeting ended Thu Nov 13 15:00:27 2014 US/Eastern.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:00 pinesol_green Minutes:        http://evergreen-ils.org/meetings/evergr​een/2014/evergreen.2014-11-13-14.00.html
15:00 pinesol_green Minutes (text): http://evergreen-ils.org/meetings/evergr​een/2014/evergreen.2014-11-13-14.00.txt
15:00 pinesol_green Log:            http://evergreen-ils.org/meetings/evergree​n/2014/evergreen.2014-11-13-14.00.log.html
15:00 jihpringle DonB: have you made any changes to the PO JEDI action trigger?
15:00 yboston kmlussier++
15:01 DonB Not that I know of
15:01 DonB I'm just a lowly cataloger
15:01 kmlussier jihpringle: Do you think somebody from SITKA could share with DonB the steps you all had to take to get EDI working with a new vendor?
15:02 jihpringle YBP doesn't come set up in the PO JEDI action trigger  like B&T does
15:02 DonB That would be great!
15:02 jihpringle kmlussier: I'll ask ldw, I'm not entirely sure what he had to do, but I know there was quite a bit involved to get it working
15:04 DonB Our IT folks are extremely busy right now with bringing up an Enterprise system. So the only way I can get there attention is with a Code Blue emergency
15:04 DonB Or if I can give them very specific instructions.
15:04 tspindler left #evergreen
15:05 DonB Instructions from a SITKA person might be enough to get some action
15:05 jihpringle DonB: I'll see what I can get for you
15:06 DonB Thanks. If it doesn't work out, it's no problem.
15:07 DonB Time to catalog some Spanish books. Bye all
15:21 kmlussier left #evergreen
15:47 hbrennan joined #evergreen
15:56 dbs hey jihpringle -- does SITKA by any chance run EDI with Coutts? We would like that :)
15:57 jihpringle dbs: no, right now we run EDI with Ingrams, United Library Services and Library Bound
16:01 dbs jihpringle: cool, thanks -- that's a pretty impressive set
16:06 jwoodard joined #evergreen
16:33 mdriscoll left #evergreen
17:05 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
17:16 mmorgan left #evergreen
17:20 buzzy joined #evergreen
18:01 kmlussier joined #evergreen
18:15 kmlussier left #evergreen
21:31 kmlussier joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat