| 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/Evergreen.git;a=shortlog;h=refs/heads/user/berick/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 |
