| Time |
Nick |
Message |
| 00:22 |
|
abowling joined #evergreen |
| 04:53 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:18 |
|
jboyer-isl joined #evergreen |
| 07:45 |
|
graced joined #evergreen |
| 07:48 |
|
akilsdonk joined #evergreen |
| 07:50 |
|
rjackson_isl joined #evergreen |
| 07:59 |
|
collum joined #evergreen |
| 08:10 |
|
Shae joined #evergreen |
| 08:41 |
|
julialima_ joined #evergreen |
| 08:45 |
|
akilsdonk_ joined #evergreen |
| 08:54 |
|
jwoodard joined #evergreen |
| 09:00 |
|
maryj joined #evergreen |
| 09:00 |
kmlussier |
It must be a good week for fielding questions on social networking sites. |
| 09:00 |
kmlussier |
In answer to this question - https://www.facebook.com/EvergreenILS/posts/798626776889988?notif_t=wall - we don't provide a virtual image anymore, do we? |
| 09:02 |
jeff |
not one that is maintained that i'm aware of. the closest/best option i would offer is a new Debian wheezy install combined with the wheezy-installer from the random git repo: http://git.evergreen-ils.org/?p=working/random.git;a=shortlog;h=refs/heads/collab/phasefx/wheezy_installer |
| 09:04 |
|
abowling joined #evergreen |
| 09:06 |
kmlussier |
jeff: OK, I'll point them in that direction then. |
| 09:06 |
kmlussier |
jeff++ |
| 09:06 |
StomproJ |
There is also the pines debian repo - apt-get install evergreen http://archive.georgialibraries.org/ |
| 09:07 |
StomproJ |
Ubuntu 12.04 only,,, so not debian. |
| 09:07 |
jeff |
StomproJ: looks like an option for -- right. :-) |
| 09:07 |
jeff |
StomproJ++ |
| 09:07 |
kmlussier |
Rather than leaving this page with a note saying it needs to be updated, should we just delete it? http://evergreen-ils.org/dokuwiki/doku.php?id=dev:quick-start_introduction_and_virtual_image |
| 09:20 |
|
Dyrcona joined #evergreen |
| 09:23 |
|
ericar joined #evergreen |
| 09:29 |
kmlussier |
Instead of deleting the page, maybe we could update it by removing everything that follows "To enable you to get hands-on with the code as quickly as possible" and adding a link to http://wiki.evergreen-ils.org/doku.php?id=server_installation:semi_automated |
| 09:31 |
kmlussier |
No, actually, I think I prefer my original idea of deleting that page. Nothing on evergreen-ils.org is linking to it right now, whereas we already seem to be linking to the automated scripts from all the right places. |
| 09:32 |
jeff |
deleting the page with no redirect or placeholder does tend to leave people at a dead end. |
| 09:33 |
jeff |
but there's some parallels to be drawn with page deletion and collection weeding. :-) |
| 09:34 |
kmlussier |
Yeah, I just hate having outdated information left out there. |
| 09:34 |
kmlussier |
It's findable in a Google search right now, but I think it stops being findable once we delete it. |
| 09:35 |
bshum |
kmlussier: I think that page mainly still exists cause we were trying to make life easier on GSoC applicants during 2013. Since we never automated VM building, I say kill it :) |
| 09:35 |
bshum |
I never liked it. |
| 09:35 |
kmlussier |
bshum: Thanks for the input. |
| 09:36 |
kmlussier |
Also adding a mental note that if we do GSoC again, we should lead them to the build scripts instead. |
| 09:36 |
bshum |
kmlussier++ |
| 09:39 |
|
akilsdonk joined #evergreen |
| 10:15 |
csharp |
StomproJ++ # mentioning the PINES repo ;-) |
| 10:16 |
csharp |
btw, it probably wouldn't be too much trouble to build debs for wheezy too, but, you know, time and stuff |
| 10:17 |
* csharp |
is sick again today :-( |
| 10:22 |
|
plura joined #evergreen |
| 10:23 |
Dyrcona |
csharp: Stop chatting and get some rest. |
| 10:23 |
Dyrcona |
:P |
| 10:37 |
|
maryj joined #evergreen |
| 10:46 |
|
sarabee joined #evergreen |
| 11:13 |
|
TaraC joined #evergreen |
| 11:44 |
* kmlussier |
is learning more than she ever wanted to know about QA. |
| 11:45 |
kmlussier |
I know we are doing build tests and some unit testing, especially after we put some of berick's guidelines from http://evergreen-ils.org/dokuwiki/doku.php?id=dev:contributing:qa into place. |
| 11:45 |
kmlussier |
But are we doing any kind of functional testing in an automated fashion? |
| 11:47 |
phasefx |
kmlussier: are you thinking UI testing? |
| 11:47 |
phasefx |
we do have the "live" tests against a running system |
| 11:48 |
kmlussier |
phasefx: No. I'm thinking, given this input the system should be returning this. |
| 11:48 |
kmlussier |
I saw the "live" tests, but wasn't exactly sure what they did. |
| 11:49 |
tsbere |
kmlussier: I think the live tests are "Given this input and a known DB state, the system should be returning this" |
| 11:50 |
kmlussier |
OK, so that's what I was looking for. I think. :) |
| 11:50 |
tsbere |
(which doesn't mean that any UI elements work, in that case, but would cover backend calls) |
| 11:50 |
phasefx |
and the unit tests are "given this input, this code chunk should always return this" |
| 11:53 |
kmlussier |
Hontestly, the way you describe it, I don't see a difference between the unit and live tests. |
| 11:55 |
tsbere |
kmlussier: The unit tests are for things that don't require the network to be up. "This utility function should always do the same thing given the same input and doesn't talk to anyone else while doing so" |
| 11:55 |
phasefx |
kmlussier: the unit tests are testing pieces of code that are very self-contained.. the live tests require a larger environment in a known state (a running system with stock test database) |
| 11:56 |
phasefx |
kmlussier: so you end up testing some interaction between multiple moving parts |
| 11:59 |
kmlussier |
phasefx: So is that the same as integration testing? |
| 11:59 |
phasefx |
kmlussier: I think so |
| 12:02 |
|
mmorgan joined #evergreen |
| 12:12 |
gsams |
Just upgraded from 2.3.5 to 2.7.3 and we are noticing problems with Overdrive authentication. The logs are showing successful attempt to access but Overdrive appears to be blocking anyway. |
| 12:13 |
csharp |
gsams: we had the same problem - it's something that changed in the EG SIP messaging... |
| 12:13 |
bshum |
gsams: I generally assume that's some sort of SIPServer problem? |
| 12:13 |
bshum |
csharp: Go rest! :P |
| 12:13 |
csharp |
gsams: in our case, Overdrive coded around it |
| 12:13 |
csharp |
bshum: :-) |
| 12:14 |
gsams |
csharp: Okay, so I can notify Overdrive that our messaging changed to be similar to PINES and they should be able to resolve. Thanks a bunch go rest! |
| 12:14 |
gsams |
csharp++ |
| 12:14 |
csharp |
gsams: yep ;-) |
| 12:17 |
|
bmills joined #evergreen |
| 12:19 |
kmlussier |
Agreed! Let it be resolved that csharp should get rest. :) |
| 12:20 |
jeff |
gsams: likely OverDrive was relying on the patron screen message field in the SIP response being "OK" -- that is no longer sent. |
| 12:21 |
kmlussier |
gsams: Congrats on your upgrade! Unfortunately, I now no longer have a go-to place to test an early release of Evergreen to verify whether a bug is new or not. ;) |
| 12:21 |
jeff |
...and I always encourage folk to NOT use SIP2 for external vendor auth, but I realize it's hard to change because inertia. |
| 12:23 |
kmlussier |
phasefx: OK, so here's my follow-up question. How do we know that we're testing all the right things with the live tests? Would it be helpful for an end user like myself to supply a set of common scenarios that should be part of the live tests? |
| 12:23 |
gsams |
kmlussier: Hehe, I wish I could still be there for that, but alas we needed these fresh new features and to actually stay up to date. |
| 12:23 |
jeff |
kmlussier: ideally, those scenarios are the input to the kinds of tests you speak of. |
| 12:24 |
kmlussier |
I just happen to have a set of test cases around overdue fines and billing that I use quite frequently. |
| 12:24 |
* jeff |
chuckles |
| 12:24 |
gsams |
jeff: now I'm curious, what would you suggest. I've always thought SIP2 was odd, but I'm not really sure why I've felt that way. I don't know enough about it to begin with. |
| 12:25 |
* jeff |
just threw a dozen or so people at the rel_2_7 (plus some cherry-picked fixes) web staff client with only a few things that broke (mostly due to permission-related quirks) |
| 12:27 |
jeff |
gsams: a lot of it depends on your needs -- we use EZproxy, but I'm likely to start moving away from it toward an emulated SSO option -- allegedly OverDrive can use a simple check via http, but that requires that the patron provide overdrive with their credentials... |
| 12:27 |
jeff |
gsams: huge can of worms. i've many thoughts on the subject, i just need to do a better job of writing them down. |
| 12:30 |
gsams |
jeff: Yeah, I figured it was more than could really be discussed in detail here. I like the sound of the other options though. YOu are totally right about inertia on SIP though. It'd be tough to stop it for sure. |
| 12:30 |
* bshum |
would attend jeff's future presentation :) |
| 12:31 |
jeff |
easiest way to avoid the inertia of using SIP2 with external parties is to never start. ;-) |
| 12:31 |
jeff |
(in our experience, at least) |
| 12:31 |
gsams |
heh, too late there! |
| 12:32 |
gsams |
Though, I like to do things the difficult way, so I wouldn't be opposed to conversion |
| 12:33 |
tsbere |
jeff: Given some of the alternatives (or lack thereof) some vendors provide to SIP2 I am not sure there is a good way to avoid starting. >_> |
| 12:34 |
jeff |
tsbere: i'm trying to gather some information on those choices -- especially for those we don't have a relationship with. i'd be interested in what you have, if you don't mind sharing. |
| 12:34 |
berick |
jeff++ # browser client testing |
| 12:35 |
tsbere |
jeff: Most of the ones I know of off the top of my head (AKA, people I actually dealt with, rather than non-technical people dealing with them first and deciding on SIP2 without ever finding out about other options) were "SIP2, don't actually validate against your system, or provide us with a URL that spits out custom specific-to-us output that we aren't willing to negotiate much on" |
| 12:35 |
tsbere |
jeff: Oh, and for half of them the URL couldn't be https. <_< |
| 12:45 |
|
sandbergja joined #evergreen |
| 12:46 |
|
sandbergja joined #evergreen |
| 12:46 |
|
sandbergja left #evergreen |
| 12:50 |
jeff |
berick: thanks! I'm immediately being pulled into something else today, but I've a handful of things to follow up on, and we're planning to give all staff test accounts and have them start kicking the tires later this week. |
| 12:50 |
jeff |
(just with concerto as a dataset, to start) |
| 12:52 |
jeff |
is anyone here having staff use the web staff client on a production system yet? |
| 12:52 |
bshum |
jeff: We aren't planning to use any web client bits in active production until more modules are complete. |
| 12:52 |
bshum |
By more I mean specifically cataloging and perhaps even acquisitions :\ |
| 12:53 |
jeff |
so no general usage at service desks for patron account management, placing holds, etc. |
| 12:54 |
bshum |
Not for us anyways. |
| 12:54 |
bshum |
At least not yet. |
| 12:54 |
* bshum |
imagines everyone will brave this stuff differently. |
| 12:57 |
kmlussier |
jeff: Nobody is using it here yet. Based on our preliminary testing, I think there is more work to be done before front-line staff will be ready to use it. eeevil and berick have been making good progress on bug fixes recently, so maybe soon. :) |
| 12:58 |
jeff |
i've applied some of those fixes to this test system :-) |
| 12:58 |
* bshum |
might also wait to see if there's anything that can be done as far as running websockets on different ports. |
| 12:58 |
bshum |
Or rather, not running it on separate ports |
| 12:58 |
kmlussier |
However, I think we'll need keyboard shortcuts before our circ staff is ready to use it. They heavily rely on the keyboard. |
| 12:59 |
bshum |
Printing might be good. |
| 12:59 |
* bshum |
hasn't tried out hatch yet. |
| 12:59 |
jeff |
bshum: why is the current websockets port setup an issue for you? |
| 12:59 |
bshum |
jeff: School firewalls |
| 12:59 |
bshum |
Mainly |
| 12:59 |
* kmlussier |
hasn't tried out hatch either. :( |
| 13:00 |
bshum |
Getting IT networks to cooperate with us isn't always an easy thing to make happen overnight. |
| 13:00 |
bshum |
And they don't always consult us when they change their equipment either. |
| 13:00 |
bshum |
And suddenly the ILS stops working. |
| 13:00 |
bshum |
brb, c4l break time :) |
| 13:00 |
* tsbere |
should try and get websockets working again for testing |
| 13:01 |
kmlussier |
tsbere: That would be great. I would love to try it out on a non-Concerto database. |
| 13:02 |
tsbere |
kmlussier: And the system(s) I was going to see about getting it to work on.......run on Concerto databases. |
| 13:02 |
kmlussier |
tsbere: But it's a first step, right? :) |
| 13:03 |
jeff |
heh |
| 13:11 |
Dyrcona |
I'm hearing that we don't want to be the first to use the web client. |
| 13:15 |
jeff |
not much of that here. we'd like to begin using it (for patron management / holds placement / light circ tasks) as soon as we're on 2.7, rather than wait until a version where the legacy staff client is no longer available. |
| 13:44 |
|
RoganH joined #evergreen |
| 13:44 |
|
sandbergja joined #evergreen |
| 13:56 |
|
ericar_ joined #evergreen |
| 13:58 |
kmlussier |
@hate winter |
| 13:58 |
pinesol_green |
kmlussier: The operation succeeded. kmlussier hates winter. |
| 13:58 |
kmlussier |
@love spring |
| 13:58 |
pinesol_green |
kmlussier: The operation succeeded. kmlussier loves spring. |
| 13:58 |
kmlussier |
@love summer |
| 13:58 |
pinesol_green |
kmlussier: The operation succeeded. kmlussier loves summer. |
| 13:58 |
kmlussier |
@love fall |
| 13:58 |
pinesol_green |
kmlussier: The operation succeeded. kmlussier loves fall. |
| 13:59 |
bshum |
@love fall |
| 13:59 |
pinesol_green |
bshum: The operation succeeded. bshum loves fall. |
| 13:59 |
collum |
@love spring |
| 13:59 |
pinesol_green |
collum: The operation succeeded. collum loves spring. |
| 13:59 |
collum |
@hate allergies |
| 13:59 |
pinesol_green |
collum: The operation succeeded. collum hates allergies. |
| 14:01 |
berick |
kmlussier: you all safe and sound in your igloos? |
| 14:01 |
|
edoceo joined #evergreen |
| 14:12 |
jeff |
no hatch for me on OS X 10.6 |
| 14:12 |
jeff |
(yes, I need to upgrade) |
| 14:13 |
kmlussier |
berick: I'm safe and sound. It's my house I'm worried about. Lots of ice dams that have nowhere to go while they melt. |
| 14:16 |
|
chick joined #evergreen |
| 14:18 |
mmorgan |
icedams-- |
| 14:25 |
mmorgan |
We implemented the Lost & Paid status once we upgraded to 2.7, now I am looking to update that status on items that were paid for previously and have status Lost. |
| 14:25 |
mmorgan |
Has anyone done this? |
| 14:26 |
mmorgan |
I'm looking at this query to identify the items: http://paste.evergreen-ils.org/32 |
| 14:46 |
jeff |
we have not. i'd recommend making sure you know if you have any closed non-zero balance transactions that you'd like to clean up first... and I'm curious how many items are being returned by your query. |
| 14:48 |
mmorgan |
jeff: My query returned 5388 items. We went live on 5/29/12, so that doesn't sound unreasonable (I don't think :)). I am concerned about erroneously closed transactions, though. |
| 14:49 |
mmorgan |
Working out a way to identify those... |
| 15:05 |
jeff |
mmorgan: this may help: https://gist.github.com/jeff/6cb257edf299fb5b6810 |
| 15:09 |
|
chick joined #evergreen |
| 15:11 |
jeff |
for historical (hysterical?) reasons, if I don't limit that to the local system I get ~150k transactions. :-) |
| 15:30 |
Bmagic |
I'm having weird grouping results. When getting metarecord results, scoped to a spceific system, http://missourievergreen.org/eg/opac/results?detail_record_view=1&query=Where+she+went&qtype=keyword&fi%3Asearch_format=&locg=174&modifier=metabib |
| 15:31 |
Bmagic |
The first result shows "Book" and "E-audio" however, when you click on it the result, you are not taken to the metabib, but instead you are taken to the E-Book which wasn't listed. |
| 15:31 |
Bmagic |
the detailed view is even more puzzling. It |
| 15:34 |
Bmagic |
It shows holdings belonging to bib 1353047 which as far as I can tell, is not included in the metabib result (however is apart of the metabib group) |
| 15:35 |
Bmagic |
/spceific/specific |
| 15:37 |
|
sandbergja joined #evergreen |
| 15:38 |
kmlussier |
Bmagic: I don't know if it's related, but I came across a problem a while back where the metabib results didn't always match the icons on the first search results page. |
| 15:38 |
kmlussier |
http://irc.evergreen-ils.org/evergreen/2014-12-18#i_145723 |
| 15:38 |
|
sandbergja joined #evergreen |
| 15:38 |
Bmagic |
kmlussier: interesting |
| 15:39 |
kmlussier |
I don't think we ever discovered what was happening here. And I don't see an LP bug. |
| 15:41 |
Bmagic |
hmmm |
| 15:43 |
|
ericar_ joined #evergreen |
| 15:45 |
kmlussier |
Bmagic: So when you say it shows holdings from another bib, you're talking about those holdings on that first search results page? |
| 15:45 |
kmlussier |
That is very weird. |
| 15:48 |
Bmagic |
yes |
| 15:49 |
Bmagic |
We recently turned on details by default, so we might be seeing things that people don't normally see. Did you click that link I posted? |
| 15:51 |
Bmagic |
kmlussier: The very first result from my link shows 2 icons. It also shows 2 copies attached to 2 different libraries. When you click the link, it takes you to the "Master" metabib id 87396. That is fine, but the grouped search results shows information about other members of the metabib |
| 15:52 |
kmlussier |
Bmagic: Yes, I saw it. I was looking around in our catalog to see if I could see something similar. |
| 15:54 |
Bmagic |
kmlussier: the fourth result "If I stay / Gayle Forman. (3) " shows 5 icons. But when you click on it, you only have 3 bibs which do not account for all 5 of the icons mentioned |
| 15:54 |
Bmagic |
kmlussier: Could it be including deleted bibs for the icons? |
| 15:58 |
kmlussier |
Bmagic: That question crossed my mind. However, record 1353047 isn't deleted, is it? |
| 15:58 |
kmlussier |
It seems like that should be displaying when you click into the grouped results. |
| 15:58 |
Bmagic |
kmlussier: no, it's not deleted. I just answered the deleted question, it's no, it's not showing deleted bib icons |
| 16:01 |
mmorgan |
jeff++ #Thanks for the link. |
| 16:01 |
kmlussier |
Bmagic: But it's not a problem when you search at the consortium level. Of course, the electronic resource isn't retrieved at the consortium level. |
| 16:02 |
Bmagic |
kmlussier: The tt2 logic decides to set the anchor tag to the master bib when there is only one. IF rec.mr_constituent_count > 1; |
| 16:02 |
kmlussier |
I wonder if located URI's area little funky with metabib search. Because the odd search result I came across back in December was related to a located URI. |
| 16:02 |
jeff |
mmorgan: did that help you? |
| 16:02 |
Bmagic |
ELSE record_url = mkurl(ctx.opac_root _ '/record/' _ rec.bre_id); |
| 16:02 |
jeff |
mmorgan: that's one of the things we're using here as part of some billing cleanup work |
| 16:03 |
kmlussier |
Correction. It was a transcendent bib. I'm getting my consortia confused. |
| 16:03 |
Bmagic |
kmlussier: so, for the first result, rec.mr_constituent_count = 1 |
| 16:04 |
mmorgan |
jeff: just got out of a meeting, will give it a try. |
| 16:05 |
jeff |
mmorgan: ah. understood. :-) |
| 16:06 |
Bmagic |
kmlussier: create a bug report? |
| 16:06 |
kmlussier |
Bmagic: Yeah, that sounds good. |
| 16:07 |
Bmagic |
kmlussier: does this seem related? https://bugs.launchpad.net/evergreen/+bug/1403907 |
| 16:07 |
pinesol_green |
Launchpad bug 1403907 in Evergreen "E-resources not included in ver 2.7.1 Group formats and editions search" (affected: 1, heat: 6) [Medium,Confirmed] |
| 16:07 |
|
sandbergja joined #evergreen |
| 16:08 |
jeffdavis |
Incidentally, at Sitka we modified parts/result/table.tt2 so that results in a metarecord search always link to the metarecord results page, never directly to the master bib, even when rec.mr_constituent_count = 1 |
| 16:08 |
kmlussier |
Bmagic: Ah, you found it! Yes, that's the one I was investigating when I came across my issue. |
| 16:09 |
Bmagic |
jeffdavis: that is interesting, I wonder if that is the answer here |
| 16:09 |
mmorgan |
jeff: your query returns 1240 for our consortium, not too much to clean up, I guess. :) |
| 16:09 |
kmlussier |
Bmagic: But it's strange. Your issue is almost the opposite of what we found. For us, we weren't able to retrieve the electronic resources. In your case, the electronic resource was the only one you retrieved. |
| 16:10 |
Bmagic |
kmlussier: yeah, something fishy is going on here. Seems to have something to do with e-resources |
| 16:10 |
kmlussier |
I'm also going to add a comment that it happens with transcendent bibs not just located URI's. |
| 16:12 |
kmlussier |
I feel dumb. If I had just read up in the IRC log I linked to, I would have seen a reference to that bug. :( |
| 16:13 |
|
mrpeters joined #evergreen |
| 16:14 |
kmlussier |
Dyrcona / tsbere: You all haven't moved to located URI's yet, have you? |
| 16:14 |
tsbere |
kmlussier: Honestly, at this point I have no clue. |
| 16:15 |
jeff |
mmorgan: you can change the SELECT from a COUNT to just SELECT mmbxs.* -- but i'd recommend using the psql command of \x to put the psql shell into "expanded display mode" -- either that, or have a very wide terminal. |
| 16:15 |
Bmagic |
kmlussier: if it makes you feel any better, I didn't discover that bug from your IRC post |
| 16:15 |
|
mrpeters left #evergreen |
| 16:15 |
jeff |
(other queries aren't that friendly/useful to go from count to select * (or foo.*) without taking time to pick and choose fields) |
| 16:18 |
* mmorgan |
generally uses phppgadmin, so select * usually isn't a problem. :) |
| 16:18 |
Bmagic |
jeffdavis: I think your idea is intersting, however, it seems like it only adds one more click. The resulting metabib page only has 1 listed, might as well just link to the bib |
| 16:19 |
* mmorgan |
usually downloads and chops out the unwanted columns in excel, or whatever. |
| 16:20 |
|
julialima_ left #evergreen |
| 16:22 |
Bmagic |
kmlussier: ok, one more clue here. The electronic link is listed in the grouped results. In this case, it is the link that is associated with the e-audio bib, which is scoped appropriatly. That bib is not included in the grouped result bib. Meaning, the server did not stuff it in the rec.mr_constituent_count array |
| 16:22 |
|
nhilton joined #evergreen |
| 16:31 |
jeff |
mmorgan: ah! then the \x doesn't matter for you there. :-) |
| 16:33 |
jeffdavis |
Bmagic: we made our change because we had cases where the one constituent record that had holdings within scope was not the master bib. So you'd get a revelant hit in your search results, but clicking the title would not take you to the relevant record. |
| 16:33 |
jeffdavis |
It may be a slightly different problem from yours, so perhaps not useful to you. In our case we decided it was worth adding the extra click. |
| 16:37 |
mmorgan |
Interesting, of the 1241 rows that match jeff's query, 24 have a positive balance, the other1217 are negative balances :-( |
| 16:38 |
kmlussier |
jeffdavis: Huh, I never noticed that before. Sounds like it might be worthy of another LP bug. |
| 16:39 |
jeff |
131 positive, 404 negative here. |
| 16:39 |
jeff |
(soon to be zero and zero!) |
| 16:39 |
kmlussier |
jeffdavis: But I really can't think of what a good solution is to that particular issue. |
| 16:41 |
|
sandbergja joined #evergreen |
| 17:00 |
Bmagic |
kmlussier: https://bugs.launchpad.net/evergreen/+bug/1420509 |
| 17:00 |
pinesol_green |
Launchpad bug 1420509 in Evergreen "Grouped metabib results shows format icons that are not included" (affected: 1, heat: 6) [Undecided,New] |
| 17:03 |
kmlussier |
Bmagic++ |
| 17:04 |
phasefx |
berick: do you have a moment where I can pick your brain? |
| 17:05 |
* kmlussier |
stares at a bunch of cases of GS cookies that needs to be moved into the garage and decides to call it a night. |
| 17:05 |
kmlussier |
Have a nice night Evergreen[st]ers! |
| 17:05 |
jcamins |
Cookies? |
| 17:05 |
kmlussier |
jcamins: Girl Scout cookies. Not the homemade kind. Sorry! |
| 17:05 |
* jcamins |
reinforces kmlussier's belief in jcamins' sixth sense for cookie mentions. :) |
| 17:05 |
phasefx |
samoas are the best |
| 17:05 |
gmcharlt |
though I see that the summon jcamins spell still works ;) |
| 17:06 |
kmlussier |
You really do have an alert in your IRC client that comes up whenever cookies are mentioned, don't you? :) |
| 17:06 |
jcamins |
Believe it or not, I don't. |
| 17:06 |
kmlussier |
phasefx: Agreed! Except we call them Caramel Delites up here. |
| 17:06 |
phasefx |
kmlussier: we have something new this year that I haven't tried yet, Rah Rah Raisin |
| 17:06 |
mmorgan |
They were better when they were samoas! |
| 17:06 |
jcamins |
I can sense when EG people are thinking about cookies, and log into irssi just to check what you guys are talking about. |
| 17:07 |
kmlussier |
phasefx: Yeah, see, that's the other bakery. We don't have those new ones. The only new ones we have are the gluten free Trios. |
| 17:07 |
phasefx |
kmlussier: ah |
| 17:07 |
kmlussier |
jcamins: I'm cookie Mom this year. Therefore, I'm always thinking of cookies. |
| 17:07 |
* jeff |
eyes the five copies of perl in his homedir with an eye toward saving some disk space |
| 17:07 |
kmlussier |
phasefx: The problem is, they made the national news, so people keep asking us for them. |
| 17:07 |
phasefx |
ruh roh |
| 17:08 |
jcamins |
kmlussier: I need a critical mass of cookie thoughts, apparently. |
| 17:08 |
kmlussier |
Oh, look, jeff is still talking about #evergreen stuff. I should take off before we get too far off topic. :) |
| 17:08 |
jcamins |
:) |
| 17:08 |
jcamins |
Have a good night. |
| 17:09 |
kmlussier |
jcamins: You too! |
| 17:09 |
* phasefx |
looks for an authtoken in his GS cookies... |
| 17:10 |
phasefx |
if I don't find one, I get to keep eating |
| 17:11 |
jeff |
Post Alpha-Bits Cereal: valid auth token in every box! some assembly required. while supplies last. before tokens time out. void where prohibited. |
| 17:11 |
berick |
phasefx: sort of, what's up? |
| 17:12 |
phasefx |
berick: may be too involved, but I'm looking at the Bill History interface, here https://webby.evergreencatalog.com/eg/staff/circ/patron/1/bill_history/transactions and am wanting to add a button to make use of those date selectors (or have an onchange on the date selectors) |
| 17:12 |
phasefx |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=blob;f=Open-ILS/web/js/ui/default/staff/circ/patron/bills.js;h=1d6f37123e882532765858162a1b307f6cd86579;hb=refs/heads/collab/miker/web-client-sprint1-bug-fixing-rebased-collab#l606 |
| 17:13 |
phasefx |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=blob;f=Open-ILS/src/templates/staff/circ/patron/t_bill_history.tt2;h=6739d7e6bf5a672bf2ea102c82ab1cc78d0eb9d4;hb=refs/heads/collab/miker/web-client-sprint1-bug-fixing-rebased-collab |
| 17:14 |
phasefx |
berick: I don't know how to do cross-talk between these "scopes", or if that's even desirable. I did try putting a button in the same scope as the grid and tried a $scope.gridControls.refresh(), but that didn't help |
| 17:14 |
phasefx |
don't know how to get it to re-query for data and rebuild itself |
| 17:15 |
phasefx |
berick: so I'm looking for advice/pointers/thoughts :-) |
| 17:15 |
|
mmorgan left #evergreen |
| 17:17 |
berick |
phasefx: defininetly do-able. going to be a minute before I can get back to you,though |
| 17:17 |
phasefx |
berick: roger that; thanks man |
| 17:19 |
phasefx |
berick: on interesting bit, is that changing those dates doesn't seem to update the model they're bound to |
| 17:31 |
phasefx |
I take that back.. they seem to be now |
| 17:41 |
berick |
phasefx: yeah, it should be updating when the dates change automatically |
| 17:42 |
|
nhilton joined #evergreen |
| 17:42 |
phasefx |
berick: I'm wondering if they're too "separated". The grid calls a function when built that gets the date range.. and the function looks at those widgets. I don't see how changing the values of the widgets would tickle the grid |
| 17:43 |
phasefx |
sorry, function looks at the variables bound to those widgets |
| 17:43 |
berick |
for ref, the BillHistoryCtrl effectively provides the parent scope for BillXactHistoryCtrl and BillPaymentHistoryCtrl. |
| 17:44 |
phasefx |
berick: roger that |
| 17:44 |
berick |
so the scope inside BillXactHistoryCtrl adopts the date_range function from BillHistoryCtrl |
| 17:45 |
berick |
so when the parent ctrlr has to refresh itself, the child ctrlr (containing the grid) should pick up the new values |
| 17:45 |
berick |
i'm fairly certain it worked before |
| 17:45 |
berick |
but it does not appear to be working for me on webby ATM |
| 17:48 |
berick |
hmm.. it might be how it's using setQuery on the grid controls |
| 17:48 |
berick |
that style may not work any more..checking |
| 17:49 |
phasefx |
berick: hrmm, I'm not seeing evidence of the date_range function even being called.. I tried putting a console.log inside of it |
| 17:50 |
phasefx |
berick: oh nevermind |
| 17:50 |
phasefx |
I had changed some code while experimenting |
| 17:50 |
* phasefx |
restores that bit |
| 17:52 |
phasefx |
okay, so I see it getting called when the grid is built, but not when the widgets are changed |
| 18:02 |
berick |
phasefx: this is not my preferred solution, but it demonstrates the problem: http://pastie.org/9937205 |
| 18:03 |
berick |
along the way, the method for telling the grid that its query has changed (and that it should update itself) evolved. |
| 18:05 |
phasefx |
berick: hrmm, should we hold of on commiting something like that for now or go for it the name of knocking out a bug? |
| 18:05 |
* phasefx |
finds it neat that you can $watch the results of a function, incidentally |
| 18:06 |
berick |
phasefx: it definitely needs to be cleaner, or a lot of code could (potentially, not really sure) get uglier. |
| 18:06 |
berick |
phasefx: can you give me until tomorrow? |
| 18:06 |
phasefx |
berick: can do, thanks man |
| 18:06 |
berick |
i'd like to dig deeper, but can't at the moment |
| 18:06 |
berick |
thanks |
| 18:06 |
* phasefx |
wants to ramp up and contribute, but it's slow going |
| 18:38 |
|
nhilton_ joined #evergreen |
| 19:26 |
bshum |
"Don't git when tired/cranky" -- this C4L talk is for you, kmlussier ;) |
| 19:26 |
bshum |
Not just you, I feel like that half the time myself. |
| 19:51 |
kmlussier |
bshum: Ha ha. No. The talk for me should simply be called "Don't git." :) |
| 20:19 |
|
bmills1 joined #evergreen |
| 20:37 |
|
bmills joined #evergreen |
