Evergreen ILS Website

IRC log for #evergreen, 2015-02-11

| 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
05:09 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
07:32 graced joined #evergreen
07:53 rjackson_isl joined #evergreen
07:55 akilsdonk joined #evergreen
07:56 akilsdonk joined #evergreen
07:57 jboyer_isl joined #evergreen
08:16 jboyer_isl joined #evergreen
08:17 akilsdonk joined #evergreen
08:18 akilsdonk joined #evergreen
08:22 mrpeters joined #evergreen
08:31 Shae joined #evergreen
09:05 Dyrcona joined #evergreen
09:06 abowling joined #evergreen
09:09 mmorgan joined #evergreen
09:17 maryj joined #evergreen
09:47 RoganH joined #evergreen
09:53 yboston joined #evergreen
09:53 jwoodard joined #evergreen
09:53 TaraC joined #evergreen
10:12 mllewellyn joined #evergreen
10:56 berick phasefx: see http://git.evergreen-ils.org/?p=working/Ev​ergreen.git;a=shortlog;h=refs/heads/user/b​erick/browser-client-grid-watch-and-bills -- 2 things going on here.
10:56 berick 1. the watchQuery function if used instead of setQuery (on the grid controls) will cause the grid to update automatically.
10:56 berick 2. in this case, though, i prefer the second commit, which is an example of how you might do the Apply button you were talking about.
10:57 berick since refreshing the grid w/ each modification to the date filter might be annoying
10:57 phasefx berick++ awesome
10:57 berick particularly if you want to change multiple values
10:58 phasefx berick: I'm curious, do you know how watchQuery works?  is it watching variables that get used within the function and then calls the function anytime one of those changes?
10:58 * phasefx agrees on the Apply button with multiple inputs
10:59 berick phasefx: it calls the function every time $digest runs (which happens any time anything changes, more or less) and it keeps track of the return value
10:59 berick with subsequent calls, it compares the previous value to the new value
10:59 berick if they are different, it calls the $watch function
10:59 berick that was provided by us
10:59 phasefx rock
10:59 phasefx berick: do you mind if I pick those into the sprint1 collab branch?
11:00 phasefx (after testing)
11:00 berick phasefx: no, i don't mind
11:00 phasefx rock
11:00 berick also, re: $watch, that's one reason you want to avoid using $watch unless necessary, because it causes extra copies of objects to have to persist.
11:01 * phasefx nods
11:02 phasefx oh, of course you know how watchQuery works, I see you're the one who implemented it :D
11:02 berick ah, i took that as a question about $watch in general
11:02 phasefx I'm coming into all of this without having learned any angular-isms yet :)
11:04 berick jumping in the deep end
11:04 phasefx fun stuff
11:04 phasefx thanks man
11:08 eeevil berick: now /I'll/ inundate you
11:10 eeevil with a pile of nested directives in a page, if all the inner directives are {transclude:true} then the scope properties from the top (conceptual) directive should be available at the leaves, even if they define a scope in the directive function, right?
11:17 berick eeevil: hm, no, i believe if a scope is defined in a directive, it does not inherit any scope data from any containing directives
11:18 berick my memory on that is not 100%, but the angular docs seem to corroborate
11:18 berick https://docs.angularjs.org/guide/directive -- 'isolate scope'
11:18 eeevil well, that's a pain
11:22 gmcharlt mmorgan++
11:35 maryj joined #evergreen
11:36 jboyer_isl Is there a generally accepted way to expand an added content section by default, or do most places just hard code it to be expanded and call it a day?
11:42 phasefx jboyer_isl: I suppose some URL rewriting is an option
11:43 jboyer_isl phasefx: I’m not opposed to just dropping ctx.expand_(whatever) = 1 into config.tt2 or something like that, I didn’t know if someone had already set up their opac in such a way that a section opens by default but can still be closed.
11:44 jboyer_isl I don’t know if I want to go to the trouble to figure it all out if it hasn’t been done yet.
11:44 phasefx I _think_ I tried something like that before and it didn't work; very fuzzy
11:46 jboyer_isl Looking at …/opac/parts/record/extras.tt2 it did look like it would be hard to get that to work. That confirms what I was thinking, thanks a lot!
11:47 julialima_ joined #evergreen
11:49 mmorgan jboyer-isl: Our added content is expanded by default. Not something I had a hand in, but here's an example: http://catalog.noblenet.org/eg/opac/record/3401840
11:51 sandbergja joined #evergreen
11:53 bmills joined #evergreen
11:55 jboyer_isl mmorgan: Thanks, I haven’t seen NOBLE’s catalog yet. I’ve seen things done a couple of different ways, this will help give me some ideas.
11:55 jboyer_isl mmorgan++
11:55 bmills joined #evergreen
11:57 akilsdonk joined #evergreen
12:05 kmlussier I wonder if there is general interest in having an easy option to expand that content by default. Because many of the people I talk to dislike having it hidden.
12:05 * kmlussier is sure there are other opinions out there, though.
12:11 graced joined #evergreen
12:13 jboyer_isl kmlussier: well, there is an easy way to do it, you just can’t collapse them later. :) (and it’s not documented that I’m aware of)
12:13 berick the opposing argument is that every bit of AC displayed (w/ some exceptions) increases the time it takes to render the page
12:14 Dyrcona jboyer_isl: Ours is like NOBLE's. After our members saw what NOBLE did, they asked us to implement it that way.
12:14 jboyer_isl That’s true.
12:14 berick options are good, though
12:15 kmlussier Ah, I was missing the point on collapsing. I don't think we have people who have been interested in collapsing them later. They just want to see them with the record.
12:17 jboyer_isl Dyrcona: Thanks, I might check out your git repo to see how that was done in case we want to move in that direction.
12:18 Dyrcona jboyer_isl: It's not in a public repo, I don't think.
12:18 Dyrcona I could cherry-pick those commits, though, into a public branch.
12:19 jboyer_isl If you’ve got time that would be great.
12:19 Dyrcona I'll be making changes to that branch this afternoon, anyway.
12:19 Dyrcona We're modifying the lowhits template.
12:20 sandbergja joined #evergreen
12:28 Dyrcona Ours also isn't strictly like NOBLE's. I think there was some stuff that we were not showing to begin with.
12:29 Dyrcona So the commit may not apply without conflicts to a clean master. I'll give it a shot.
12:30 Dyrcona Nope. Looks like it did.
12:30 jboyer_isl I didn’t think there had been a lot of movement in those files for a little while.
12:31 Dyrcona Well, we may have made some changes before adding the changes from NOBLE was my concern.
12:31 jboyer_isl I see.
12:32 Dyrcona Here you go: http://git.mvlcstaff.org/?p=jason/ILS.git;a​=shortlog;h=refs/heads/expand_added_content
12:32 Dyrcona It says "first attempt," but turns out we got it right the first time.
12:36 Dyrcona Hmm. Guess before I go messing with the lowhits template, I'll branch my branch.
12:37 Dyrcona NOBLE++
12:38 mmorgan Dyrcona++
12:50 collum joined #evergreen
12:52 Callender joined #evergreen
12:56 Stompro joined #evergreen
13:11 maryj joined #evergreen
13:14 akilsdonk joined #evergreen
13:35 jboyer_isl Ooh, thanks.
13:35 jboyer_isl Dyrcona++
13:35 jboyer_isl mmorgan++
13:45 jeff OneClickdigital just added SIP2 for patron auth.
13:45 * jeff weeps
13:47 graced joined #evergreen
13:48 dkyle left #evergreen
14:02 kmlussier eeevil: I'm having a hard time following what's going on in web-client-sprint1-bug-fixing-rebased-collab. Is there a way the web client fixes could be put into smaller, more manageable branches so that we could begin pushing things into master?
14:02 kmlussier I think it would also be good if the new cataloging work were in a different branch than the sprint 1 fixes.
14:06 eeevil kmlussier: it's possible, but TBH, I don't see much point. the new code needs the fixes, and I don't see a reason for the new code not to go in.  the sprint1 code was lacking functionality per the sprint docs (that I've added in the fixes branch -- new functionality, but not sprint2), so I don't think there's actual precedent for holding back partial sprint code
14:06 eeevil (sorry if that seems overly blunt ... just meant to convey my thoughts succinctly ;) )
14:06 DPearl joined #evergreen
14:09 eeevil kmlussier: unrelated to the web client, I pushed a change for the don't-change-0-balance-lost-xact branch, per the situation you identified ... not sure if you saw that
14:10 kmlussier eeevil: Sure, I'm okay with pushing them in as is because, as far as I know, nobody is using the web client yet. I'm just having a hard time managing my own testing of the new code.
14:10 kmlussier eeevil: I did see that. Thanks! :)
14:11 * bshum has been likewise confused by the status of that collab branch
14:11 bshum Is there a specific block of commits we should focus on getting into master first?  Or are we just expecting to push the whole thing enmasse?
14:11 kmlussier Also, all the code I've reviewed so far has improved the web client, so +1 to getting it in.
14:12 * bshum also assumes none of it is being backported to rel_2_7 then.
14:12 bshum Though, they are "bug fixes"?  Meh
14:14 eeevil kmlussier: right. IIRC, the consensus was folks should wait until they can do OneBigSwitch(tm) to the web client. now, whether folks will... :)
14:14 * kmlussier doesn't remember that consensus
14:15 kmlussier Would it help if I signed off on the commits I already tested?
14:15 kmlussier I know I had further feedback on some of those commits, but I only saw improvements in what I tested.
14:15 DPearl I'm attempting to build a Concerto database; it worked some time ago, but there was a concerto.sql file to read in.  Things have changed and concerto.sql is no longer there.  The eg_db_config.pl is gone and replaced by an .in file, so current instructions to build the db don't work! Where should I look for the new doc?
14:15 eeevil kmlussier: I imagine it would, or at least note them. I'm not sure how berick wants to handle that merge
14:18 bshum eeevil: Can sprint1 fixes be un-entangled from the collab from sprint2 stuff?  Or do we have to test all the things before the branch can be moved forward in any way?
14:18 kmlussier OK, I'll do some sign-offs. But I still would like to advocate for putting the new cataloging code into a different branch from the circulation fixes.
14:19 kmlussier Ha ha. What bshum said.
14:19 * bshum is just trying to help, not trying to be difficult.  I just work better in more concrete blocks of things to look at.
14:19 Dyrcona DPearl: You have run configure at least to get eg_db_config.pl from the eg_db_config.pl.in file.
14:20 Dyrcona You'll probably need to autoreconf -i first if you're working from a git clone.
14:22 kmlussier eeevil: Take it as a positive sign that lots of people are interested in looking at the web client fixes. :)
14:25 DPearl Dyrcona: Thanks
14:27 jeff I'd like to see the web staff client fixes backported to 2.7 -- if it's a matter of signoff/tuits, I can probably scrounge up some tuits here. If it's a matter of more fundamental opposition to them being backported, I guess tuits don't help.
14:28 bshum jeff: I might consider that, if the fixes were more distinct in the branch from the new stuff for cataloging sprint2.
14:28 bshum :)
14:29 bshum But as is, it's a jumble that I'm still reading through.
14:33 julialima_ joined #evergreen
14:37 eeevil kmlussier / bshum: sorry, stepped away.  I'm glad folks want to look at any of it :)
14:42 eeevil the cataloging changes really need everything else (or, substantially), and since nobody has jumped in to help with coding things they find broken, I chose to reduce the overhead of making progress.  I can start a new branch called "sprint2" if that would help, but it'll just be a clone of the sprint1 branch. will it provide a lot of help to remove any sprint2 code in another copy of the collab branch?  (I'll personally
14:42 eeevil consider that branch a dead end, fwiw, because I don't see much point in shuffling commits all over the place when there's really only going to be just a couple developers working in tight coordination)
14:44 eeevil now, if folks started to show an interest in getting involved in either initial coding of features beyond the current plan, or bug fixing (to learn angularjs, or just because), then the multi-branch-parallel-to-master world would make sense
14:52 kmlussier Heh, I don't think anyone wants me diving into angularjs, but I'll do what I can to sign off on stuff as soon as I test it, which might make things more manageable.
14:54 Dyrcona My bosses have other ideas how I should spend my time right now.
14:54 dbs Having small branches is probably the best way for people to learn how to start digging in.
15:11 eeevil dbs: that's probably true when the small branches are tracking a canonical master branch, but in this case we're talking about (at least) two branches tracking both master and another "fix" branch, which has to track master, too, leading to periodic manual, cascading rebases ... AFAICT. I can do that or write code :).  if folks think of the collab branch as the "master for web client -- for now", then they can branch from
15:11 eeevil that and I'll happily pick things into the "master collab". am I overlooking something?
15:13 eeevil bshum / jeff: I'd advise against backporting web client stuff, myself, but I'm not the RM :)
15:14 Dyrcona I would have given the same advice, but bshum sounded reluctant enough for me.
15:17 berick what's the harm in back-porting browser client bug fixes?
15:18 sandbergja joined #evergreen
15:22 Dyrcona Probably none, but I got the impression that they are intertwined with new development.
15:28 gsams Any chance someone has built a 2.7.3 staff client?
15:28 gsams for mac
15:29 gsams specifically
15:29 gsams because that would be an important detail
15:34 jboyer_isl gsams: a couple of us have talked about making them when new releases come out, but I don’t think anything has come of it yet.
15:34 ningalls mac gets no love
15:35 mmorgan gsams: I could offer you a 2.7.2 one, but I don't think that would help :-(
15:36 jboyer_isl ningalls: It does here, but that doesn’t help anyone using a stock release.
15:36 gsams I attempted to build one, but it keeps coming up damaged, without a mac to actually work with here I can't seem to get it to work
15:38 jboyer_isl gsams: Does your Info.plist have a Bundle Identifier in it? There was a point that Mac OS X got really picky about that, and that was not originally in the instructions.
15:39 kmlussier Dyrcona / berick: I didn't get the idea that bug fixes were dependent on the new features. I thought it was the opposite: the new features were dependent on bug fixes that hadn't been pushed into master yet.
15:40 pastebot "gsams" at 64.57.241.14 pasted "Info.plist" (26 lines) at http://paste.evergreen-ils.org/33
15:40 phasefx gsams: I don't think there have been any local client changes that would warrant a new client; you could probably get away with one from 2.6 or mmorgan's 2.7.2 client.  You just need to add a symlink for it in /openils/var/web/xul/ on your apache servers
15:40 gsams jboyer_isl: that's what I've popped in, following the instructions found: http://evergreen-ils.org/dokuwiki/doku.php?​id=mozilla-devel:building_the_staff_client
15:42 gsams phasefx: I'd be willing to try that out
15:43 gsams mmorgan: have a link to your client?
15:44 mmorgan gsams: just a sec
15:47 berick kmlussier: in that case, we always have the option of backporting select fixes into 2.7 after they are merged into 2.8/master.
15:47 berick if that makes the initial code push any easier
15:48 mmorgan gsams: does this work? http://www.noblenet.org/Evergreen_2.7.2.app.zip
15:49 berick arg, i need to schedule a dev meeting
15:49 gsams That appears to work, downloading it now
15:49 gsams jboyer_isl++
15:49 mmorgan Can't take credit for building this myself. One of my colleagues builds the mac versions as soon as we upgrade. Hope it works for you.
15:49 gsams mmorgan++
15:49 gsams phasefx++
15:49 gsams mmorgan: I'll remain hopeful!
15:51 Bmagic when "Retain empty bib records" is not set, does the default behavior delete the bib?
15:52 bmills joined #evergreen
15:52 bshum Bmagic: That sounds right.
15:53 Bmagic bshum: thanks
16:00 kmlussier Yikes! beta cutoff is 1 1/2 weeks away?
16:13 gmcharlt kmlussier: time flies when we're having fun
16:13 kmlussier gmcharlt: Fun?
16:13 gmcharlt yes!
16:13 gmcharlt docs! \o/
16:13 gmcharlt patches! \o/
16:14 gmcharlt regression tests \o/
16:14 gmcharlt too much coffee! \o/
16:16 dbwells I was still thinking the cutoff was the 18th, but I now see it got pushed to the 20th.  Two extra days!   \o/
16:51 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
17:04 eeevil joined #evergreen
17:05 sarabee joined #evergreen
17:11 mmorgan left #evergreen
17:29 berick kmlussier++ # signoffs
17:30 berick for the browser client, that is
17:59 yboston kmlussier: are you still available?
18:00 yboston do you want me to send out a reminder for the Evergreen for Academics meeting tomorrow?
18:22 sandbergja joined #evergreen
21:44 geoffsams joined #evergreen
22:01 Sato joined #evergreen
22:13 dcook joined #evergreen
22:38 dcook joined #evergreen

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