| 10:58 |
* jeff |
nods |
| 10:59 |
jeff |
down-then-over vs over-then-down |
| 10:59 |
jeff |
consistency is important there |
| 10:59 |
mdriscoll |
Dyrcona: I would be happy to test your branch when you get it done |
| 11:01 |
dbwells |
Okay, feel free to keep talking about layout, but we have more questions! :) |
| 11:01 |
jeff |
do the single row and grid examples allow presenting more information when you're looking at the "form" not because you're editing, but because you're reviewing / seeking information? item status single-row display vs item attribute editor single-row display being one example -- would we consider moving the item status display move to single column? |
| 11:03 |
dbwells |
jeff: That's a good point. I don't have a good answer, but I do think the concept of dual purpose display/edit screens should be carefully considered. |
| 12:36 |
|
maryj joined #evergreen |
| 12:38 |
goood |
dbs: or they could just consider the "collab" branch as the "master" to target, and submit branches against that. not seeing the difference, really |
| 12:41 |
dbs |
Right. So why aren't bug fixes and small features being merged to master on a regular basis again? |
| 12:42 |
goood |
dbs: because folks don't test (save kmlussier) or merge, and I get smacked whenever I merge my own code, and get the side eye when I merge my coworkers' code without further review |
| 12:44 |
goood |
s/further review/non-esi review, for whatever personal reasons various folks may have/ |
| 12:49 |
|
nhilton joined #evergreen |
| 12:57 |
|
bmills joined #evergreen |
| 13:09 |
mrpeters |
Alrighty guys -- I'm in Action/Trigger hell and have come to beg for mercy! See http://pastie.org/9945103 -- an event_def to mark an item lost 3 hours after it goes overdue. Nothing fancy, pretty similiar to the stock 90 Day Lost notice. Each time the event runs, it ends with a state 'error' but I'm struggling to find more information about what caused the error. Pertinent osrfsys logs are at http://pastie.org/private/l62y4g3wodwvxhw2iwrdg -- Eve |
| 14:13 |
dbwells |
My sense when he mentioned it last week was that he felt obligated to work on it since he had already done some work on it. My guess is he'll be very happy to see you've completed it. |
| 14:15 |
Dyrcona |
I felt obligated to work on it when a Backstage import busted up someone's work. :) |
| 14:15 |
Dyrcona |
That's cool. Collaboration is nice. |
| 14:24 |
Dyrcona |
While testing that change, I noticed something unusual. |
| 14:25 |
Dyrcona |
Any time I typed a key in the marc editor, regular or flat text, while editing a record to import, a JavaScript error window would pop up. |
| 14:26 |
Dyrcona |
TypeError: tab is undefined |
| 14:26 |
Dyrcona |
Still doing it, actually. |
| 14:26 |
Dyrcona |
MARC edit works fine on regular bibs. |
| 14:27 |
Dyrcona |
Guess I'll do a git clean and see what happens. |
| 14:27 |
kmlussier |
dbs: Thanks for letting me know about mlnc4. I'll fix it up now. |
| 14:28 |
dbwells |
Dyrcona: I saw that too, when testing master with a 2.7 client. I know it stems from some changes ldw wrote a while back, and I thought it might be related to me needing a new client. |
| 14:28 |
dbwells |
Are you seeing it with a master client? |
| 14:28 |
Dyrcona |
Yes. |
| 14:29 |
Dyrcona |
My script builds a fresh client when I build all of Evergreen. |
| 14:29 |
Dyrcona |
Guess that's a bug. |
| 14:45 |
|
Tony__ left #evergreen |
| 14:46 |
|
akilsdonk joined #evergreen |
| 14:50 |
Dyrcona |
Hmmm. I have that commit, so something about it must still be wrong. |
| 14:53 |
kmlussier |
dbs / eeevil: Would it be worthwhile to discuss the web client merging at the next dev meeting? I don't know what the answer is, but I personally would love to see the code make it into master faster. |
| 14:54 |
kmlussier |
One thing I'm up against is that I have a few people on hand to help test the circ changes, but we aren't geared up to test cataloging yet. However, I don't really know if the other circ code in that collab branch is dependent on some of the cataloging features that come before it. |
| 14:55 |
kmlussier |
So signoffs there may not be helpful. |
| 14:56 |
kmlussier |
And mlnc4.mvlcstaff.org is up and running again. |
| 14:57 |
* kmlussier |
should add something to her calendar to update it monthly. |
| 15:03 |
Dyrcona |
Well, the diff isn't telling me much, and neither is JavaScript console. |
| 15:03 |
Dyrcona |
I may have to call on Venkman. |
| 15:04 |
Dyrcona |
If he's still around somewhere. |
| 11:11 |
csharp |
berick: ewww |
| 11:11 |
kmlussier |
berick++ |
| 11:18 |
Dyrcona |
heh |
| 11:22 |
berick |
eeevil: kmlussier: going to merge working/user/kmlussier/web-client-sprint1-bug-fixing-signoff1 (plus 9804b5c54d12e6f2d1ae7b907a0de80d84ff978f) after light testing. any issues/concerns before I do that? |
| 11:24 |
kmlussier |
I have no concerns |
| 11:25 |
berick |
note for later, we should make the grid less chatty in the console. |
| 11:25 |
berick |
kmlussier: thanks |
| 11:25 |
goood |
berick: just concerns over rebasing the remainder... but that can be a tomorrow problem, I suppose |
| 11:29 |
jeff |
oh and of course the lovely thing about running services on high ephemeral ports... |
| 11:29 |
jeff |
(well, ONE of the things)... sometimes someone else gets there first. :P |
| 11:29 |
berick |
goood: rebasing collab/miker/web-client-sprint1-bug-fixing-rebased-collab ? |
| 11:33 |
berick |
just tried an expirement, rebasing that ^-- to my about-to-merge master branch. i haven't tested it, but it rebased without conflict. |
| 11:33 |
berick |
so there's that |
| 11:42 |
hopkinsju |
Does Evergreen actually use the quality field in biblio.record_entry? I can't think of anything, and we were thinking about reusing that column. |
| 11:44 |
jeff |
hopkinsju: have you considered biblio.record_note? |
| 11:44 |
|
sandbergja joined #evergreen |
| 11:55 |
bshum |
mmorgan: Now you're getting it! :) |
| 11:55 |
kmlussier |
Yeah, probably. I don't think it matters much. I guess I've just been looking at them far too much over the past year. |
| 11:55 |
berick |
bshum: git filter-branch -f --msg-filter "sed '0,/^/s//LP\#1402797 /1'" origin/master.. |
| 11:56 |
bshum |
If you come up with better categories for things, I'm happy to help test/push that along. One of the things I always wish I had more time to do would be to go back and actually add meaningful descriptions to all YAOUS entries. |
| 11:56 |
berick |
(then had to clean up a few double-tagged commits) |
| 11:56 |
bshum |
berick: Ooooh, fancy! |
| 11:56 |
kmlussier |
bshum: Yeah, adding better descriptions has crossed my mind too. |
| 11:56 |
* berick |
credits gmcharlt with the original suggestion way back when |
| 11:59 |
yboston |
Hello, I can't remember what the rules are for the deadlines we use for having a code change make it to the next release. I see the calendar says that next Friday is the "2.8 Beta Cut-Off" I can't remember what that one is for, I think it is meant for testing and signing off bug fixes? I beleive that the previous "2.8 Feature LP Target Deadline" is for havign signed off changes make it to the beta? |
| 11:59 |
bshum |
kmlussier: "Charge lost on zero" confused me for years. Still does sometime... |
| 12:00 |
berick |
yboston: the 2.8 cut off is for new features only. we *always* accept bug fixes |
| 12:00 |
bshum |
bug_fixes++ |
| 12:00 |
bshum |
:) |
| 12:00 |
yboston |
berick: sorry, that was the one rule I did remember, that bug fixes are always accepted :( |
| 12:00 |
kmlussier |
Is it difficult to update records that are provided in the Concerto set? I keep thinking it would be nice to add prices for all of the copies in there. |
| 12:01 |
kmlussier |
So that when you mark them lost in testing, a bill is added to the patron record. |
| 12:01 |
berick |
yboston: no worries, did I answer your question, though? |
| 12:01 |
bshum |
kmlussier: I'm sure it's not hard to do that. |
| 12:01 |
yboston |
so is there still time to submit (signed off) changes for 2.8? |
| 12:04 |
berick |
yboston: documenting / targeting new features in launchpad. the absence of such documention does not prevent new features getting into 2.8, though |
| 12:04 |
berick |
the purpose was to get as much info out as early as possible |
| 12:04 |
yboston |
berick: thank you very much, I had assumed I missed the boat on a new feature |
| 12:06 |
berick |
yboston: speaking of, do you still have any expectation of testing bug #1171984 ? |
| 12:06 |
pinesol_green |
Launchpad bug 1171984 in Evergreen "add support in Vandelay for overlaying authorities during import using match sets" (affected: 5, heat: 22) [Wishlist,Confirmed] https://launchpad.net/bugs/1171984 |
| 12:06 |
yboston |
berick: so sorry |
| 12:07 |
pinesol_green |
Showing latest 5 of 45 commits to Evergreen... |
| 12:08 |
berick |
and I thought we were immune down here ;) |
| 12:08 |
berick |
yboston++ |
| 12:09 |
|
bmills joined #evergreen |
| 12:10 |
kmlussier |
berick: If yboston doesn't get to that one, I might be able to. I was just looking at it today. |
| 12:10 |
kmlussier |
Or, I should say, eyeing it as a possible thing to test. |
| 12:11 |
berick |
kmlussier: awesome |
| 12:11 |
* berick |
pushed a rebased-to-master branch |
| 12:11 |
yboston |
kmlussier: I will let you know if I start testing it so you don't have to, then again maybe the more tsts the better |
| 12:13 |
|
sandbergja joined #evergreen |
| 12:13 |
* berick |
needs to come up w/ a conference proposal |
| 12:13 |
|
akilsdonk joined #evergreen |
| 12:37 |
geoffsams |
Of Course I haven't looked at the specific pages that have been brought up either |
| 12:41 |
|
maryj joined #evergreen |
| 12:47 |
kmlussier |
gsams: 98/100 sounds pretty good |
| 12:48 |
gsams |
kmlussier: That's for the advanced search page at least |
| 12:49 |
gsams |
Since I'm 4 days after an upgrade I haven't had time to do more testing |
| 12:49 |
kmlussier |
I'm interepreting that as 98 out of 100. |
| 12:49 |
gsams |
that is correct |
| 12:49 |
gsams |
The only usability changes it suggested were related to tap targets spacing and size |
| 12:52 |
gsams |
basically, Basic Search and Browse the Catalog are too close, The search input boxes are too close, and we have a link at the bottom that is too close to other things |
| 12:56 |
goood |
hopkinsju: quality is use for lead metarecord selection. can you give some context to your "scoring algorithm"? what are you scoring, how do you interpret a score value, and what questions are answered by the score |
| 13:00 |
|
krvmga joined #evergreen |
| 13:01 |
bshum |
Hmm, c4l lightning talk about "keyboard accessibility" makes me think about how much testing we're doing on the catalog / web client. |
| 13:01 |
bshum |
So much stuff to test. |
| 13:03 |
|
sandbergja left #evergreen |
| 13:05 |
kmlussier |
bshum: Well, there currently isn't much to test in the web client in terms of keyboard accessibility. I don't think the keyboard shortcuts have been included yet. |
| 13:06 |
kmlussier |
yboston: Are you still around? |
| 13:07 |
|
afterl joined #evergreen |
| 13:33 |
yboston |
kmlussier: I am back at my desk |
| 13:34 |
goood |
berick: the removal of dropdown-toggle on the actions in the grid (commit d37e4d0bba) means, for ng 1.2.22 (on webby), that the menu stays open after the launching the action. Is that just an "old ng" problem? |
| 14:11 |
kmlussier |
yboston++ |
| 14:11 |
yboston |
bug #1171984 |
| 14:11 |
pinesol_green |
Launchpad bug 1171984 in Evergreen "add support in Vandelay for overlaying authorities during import using match sets" (affected: 5, heat: 22) [Wishlist,Confirmed] https://launchpad.net/bugs/1171984 |
| 14:12 |
yboston |
this is a feature that needs to be tested out for inclusion in EG 2.8. Again there is one week left to have someone test it and "sign off" on it |
| 14:12 |
yboston |
Kathy or I will try to do the signing off |
| 14:13 |
yboston |
I am bringing this up partially to showcase how improvements are made to EG |
| 14:13 |
yboston |
that is all for me on authoritites. I can move to the nexr past meeting's action item |
| 14:13 |
|
Cybrarian joined #evergreen |
| 14:14 |
yboston |
moving on |
| 14:14 |
yboston |
3) jeffdavis to put out a call for current patron loading scripts that are already in use. |
| 14:14 |
yboston |
I am not sure if jeffdavis is available now, will wait a bit before defring |
| 14:15 |
yboston |
moving on |
| 14:15 |
yboston |
#action jeffdavis to put out a call for current patron loading scripts that are already in use. |
| 14:15 |
yboston |
at this point there are now more outstanding past meetign action items |
| 14:15 |
yboston |
we can now shift to talk about other issues |
| 14:16 |
yboston |
for example, thoughts on the earlier discussion on call number search |
| 14:16 |
yboston |
or something completely different |
| 14:16 |
Cybrarian |
PAC flavors? |
| 14:16 |
DonB__ |
I sent out a couple of emails to the list regarding call numbers |
| 14:17 |
DonB__ |
It seems there is broad consensus in two areas |
| 16:52 |
* Dyrcona |
typoed Integer as Interger last night. |
| 16:52 |
Dyrcona |
That'll do it. |
| 16:52 |
RoganH |
I did it once before which is why I suddenly thought of it. |
| 16:53 |
RoganH |
I discovered that one before testing though. Ug. |
| 16:57 |
RoganH |
That did it. Thanks for the ideas all. |
| 16:57 |
RoganH |
Dyrcona++ |
| 16:57 |
RoganH |
kmlussier++ |
| 17:04 |
gsams |
kmlussier++ |
| 17:04 |
kmlussier |
gsams: Awesome! |
| 17:04 |
RoganH |
Good night! |
| 17:07 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:07 |
|
mdriscoll left #evergreen |
| 18:02 |
|
bbqben joined #evergreen |
| 18:12 |
|
mrpeters left #evergreen |
| 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 |
| 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. |
| 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: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 |
| 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 |
| 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 |
| 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: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: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. |
| 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? :) |
| 12:37 |
csharp |
damn - I can't find the problem |
| 12:37 |
csharp |
fieldmapper looks right, rocit.age_protect <-> crahp.id |
| 12:44 |
csharp |
@hates |
| 12:44 |
pinesol_green |
csharp hates dojo_hold_policies_interface; SIP; when libraries purchase third party products without testing and blame Evergreen for it not working; reports; the fact that the Base Filters is unnecessarily greyed out when applying an Aggregate Filter and vice versa; evil; reports more; reports even moar; details; reports even more; the fact that the Base Filters is unnecessarily greyed out (1 more message) |
| 12:45 |
csharp |
@more |
| 12:45 |
pinesol_green |
csharp: when applying an Aggregate Filter and vice versa even more; having to teach SIP2 client vendors about the SIP2 specification; troubleshooting reports; money reports; and marc |
| 12:45 |
|
mmorgan1 joined #evergreen |
| 15:12 |
|
julialima_ left #evergreen |
| 15:19 |
|
mmorgan1 joined #evergreen |
| 15:34 |
|
kmlussier joined #evergreen |
| 16:04 |
* jeff |
is seeing "grunt test" fail in rel_2_7 and master at present |
| 16:04 |
jeff |
since I haven't run these tests before, I'm not sure if I'm doing something wrong. |
| 16:06 |
berick |
got a paste? |
| 16:06 |
jeff |
output is here: https://gist.github.com/jeff/45f872e1899ba6217cd0 -- it obviously can't find/load angular, but i'm not sure where to start |
| 16:08 |
jeff |
oh hey, and now it works. |
| 17:06 |
mrpeters1 |
sorry, i got distracted and didn't finish my thought there -- should a 1 hour overdue have a 1 hour processing delay? |
| 17:06 |
mrpeters1 |
wouldn't that cause a notice not to be sent until it was actually 2 hours overdue? also, the Max Event Validity -- its set to 2 hours -- if a cron job failed to run to "run pending" within that 2 hour window, would that cause the notice to fail to be sent? |
| 17:10 |
|
mrpeters1 left #evergreen |
| 17:11 |
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 |
|
mmorgan1 joined #evergreen |
| 17:20 |
|
abowling joined #evergreen |
| 17:22 |
|
mmorgan1 joined #evergreen |
| 12:48 |
gmcharlt |
goood: http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/collab/gmcharlt/better_osrf_control_diagnostic |
| 13:02 |
kmlussier |
Woo hoo! Booked my hotel room for the conference. :) |
| 13:08 |
|
nhilton joined #evergreen |
| 13:13 |
phasefx |
berick: I was trying a variant of the script in bug#1268619 to test websockets prior to installing anything EG (including dojo). And I found I had to include opensrf_ws.js manually, and after calling .send(), I also had to call .session.send_ws() on the request object. Does that sound crazy? |
| 13:16 |
phasefx |
http://paste.lisp.org/display/145683 |
| 13:19 |
phasefx |
the manual part doesn't sound crazy, the path is hard-coded in opensrf.js |
| 13:21 |
phasefx |
okay <rubber ducking>, so if I change the transport from OSRF_TRANSPORT_TYPE_WS_SHARED to OSRF_TRANSPORT_TYPE_WS, I can just do req.send() and it works |
| 13:24 |
berick |
phasefx: OSRF_TRANSPORT_TYPE_WS_SHARED is currently disabled. send_ws() is the underyling handler for OSRF_TRANSPORT_TYPE_WS. |
| 13:24 |
berick |
so even though it was set to OSRF_TRANSPORT_TYPE_WS_SHARED, you were forcing it to run as non-shared by calling send_ws() directly |
| 13:25 |
berick |
when you changed to OSRF_TRANSPORT_TYPE_WS, the send_ws() was no longer needed |
| 16:28 |
|
nhilton_ joined #evergreen |
| 16:41 |
csharp |
amazing... with dbwells's fix with jboyer-isl's modifications, my nearly two-hour query dropped to 4 seconds |
| 16:45 |
|
nhilton joined #evergreen |
| 16:48 |
dbwells |
csharp: Sorry for being lazy on the COALESCE, I only did a quick test on lower ids which had a legacy_circ_count entry (which should be, I think, the only number needing a COALESCE). |
| 16:56 |
dbwells |
This should work: http://pastie.org/9893249 |
| 17:01 |
dbwells |
I also kept COUNT(*) over COUNT(distinct id) because 1) there are no joins involved, so DISTINCT doesn't do anything for us here, and 2) COUNT(*) is generally recommended when simply counting rows, as it lets the planner pick whatever it thinks is best (which will probably be 'id', but anyway... at least that's what I've been told). |
| 17:05 |
dbwells |
In any case, the changes I'm advocating will not affect performance in any measurable way, I think it just helps readability. |
| 17:06 |
|
vlewis_ joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:16 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:30 |
csharp |
dbwells: excellent - thank you |
| 17:31 |
csharp |
I'll file a bug on this just to get it on the record |
| 17:32 |
dbwells |
sounds like a plan |
| 09:09 |
bshum |
jeff: How did those slip past? |
| 09:11 |
jeff |
bshum: staff-side patron editor has no checks for duplicate holdshelf alias. We didn't put effort into closing that loophole. |
| 09:11 |
bshum |
Ahh. |
| 09:11 |
jeff |
bshum: So at least one of each group is staff or asked staff to set their alias to that value. |
| 09:11 |
|
sarabee joined #evergreen |
| 09:12 |
jeff |
looking, the duplicate catwoman is a test/training account's alias. |
| 09:12 |
|
eeevil joined #evergreen |
| 09:18 |
mmorgan |
jeff: speaking of popular - what are you looking at to get the "most popular" titles on your stats page? Circs? Holds? A combination? |
| 09:36 |
jeff |
mmorgan: i think i owe you an email regarding that, too! |
| 10:04 |
eeevil |
pcrud.js is completely unchanged (now... I was messing with it last night) |
| 10:11 |
berick |
eeevil: ok, was able to reproduce locally |
| 10:11 |
* berick |
pokes |
| 10:12 |
eeevil |
berick: I suspect, but haven't tested, that it happens with every pcrud CUD call |
| 10:31 |
|
dreuther joined #evergreen |
| 10:34 |
|
dMiller_ joined #evergreen |
| 10:36 |
berick |
eeevil: found it. good stuff |
| 10:36 |
berick |
http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=commitdiff;h=1b25f487c0acdfa000becbccac6943e24bc0ca77 |
| 10:36 |
berick |
i'll open an LP |
| 10:37 |
berick |
this code path (per-tab connections) got much less testing than the global WS connection code, which had to be disabled, because chrome started acting funky with global connections |
| 10:37 |
berick |
will have to revisit that.. |
| 10:42 |
|
mrpeters joined #evergreen |
| 10:46 |
berick |
https://bugs.launchpad.net/opensrf/+bug/1418613 |
| 10:46 |
pinesol_green |
Launchpad bug 1418613 in OpenSRF "Per-tab websocket JS connections can re-send messages" (affected: 1, heat: 6) [Undecided,New] |
| 11:01 |
bshum |
berick: I'm adjusting that entry if I can so that it points at OpenSRF 2.4.1 |
| 11:01 |
bshum |
Since 2.4.0 was already released last month |
| 12:09 |
bshum |
gmcharlt: Sorry I'll fix up 2.7.3 too and create a 2.7.4 for everyone. |
| 12:09 |
bshum |
Old, old bug. Back from my 2.0 days :( |
| 12:10 |
gmcharlt |
bshum: ah, great - thanks for catching that! |
| 12:11 |
bshum |
gmcharlt: I'm not sure if dbwells has cut 2.6.6. He might not have yet and it could still get tested and applied there. But more than likely I expect we'll keep that lock-step on bug fixes in general. |
| 12:11 |
bshum |
gmcharlt++ # poking at ancient bugs |
| 12:12 |
gmcharlt |
bshum: that's fine - that bug gets hit rarely enough, I think, that testing doesn't need to be super-rushed |
| 12:12 |
gmcharlt |
our_customers++ # running into ancient bugs and KEEPING THEM ALIVE |
| 12:13 |
bshum |
Reported by Ben Shum on 2011-12-15, zomg :( |
| 12:13 |
* bshum |
can't believe how long it's been :\ |
| 12:14 |
bshum |
Stompro++ # helping to announce new release on list with helpful notes and links! |
| 14:41 |
remingtron |
I think I did, but probably asked bshum first |
| 14:41 |
remingtron |
basically, he wrote the instructions draft, and he wants some feedback |
| 14:42 |
remingtron |
maybe he/we should ask the general and dev lists for help on that |
| 14:42 |
yboston |
ats ome point I need to build a new test server to try out the web client, I can give him some feedback at that point |
| 14:43 |
yboston |
I can put an action item to reach out to him to see if this has been included in master, and if others have been able to run his intructions |
| 14:43 |
yboston |
they look fine to me, bu I have nos tested them yet |
| 14:43 |
bshum |
It has not been added up to master yet. |
| 14:43 |
bshum |
Sorry, stepped away a sec there. |
| 14:44 |
bshum |
I'll work on it with more devs in the coming weeks. |
| 14:44 |
yboston |
I can reach out to you when I am ready to build a new VM to test the web client, to make sure I use the latest version |
| 14:45 |
yboston |
is there a git branch that has these instructions? |
| 14:45 |
bshum |
yboston: I haven't put all the changes into a git branch yet. That's also on my to-do list I think. |
| 14:45 |
yboston |
no worries |
| 14:46 |
yboston |
I can move on, but want suggestions on what action item if any we should leave for next meeting for this? |
| 15:02 |
remingtron |
kmlussier: are you able to make the wiki page for 2.8 features again? |
| 15:03 |
kmlussier |
Yes, I can. |
| 15:03 |
kmlussier |
Sorry, I was pulled into another discussion. |
| 15:03 |
* gmcharlt |
jumps in to mention that I intend to provision the doc testing server next week |
| 15:03 |
gmcharlt |
sorry for hte delay |
| 15:03 |
kmlussier |
gmcharlt++ |
| 15:04 |
yboston |
no problem, you have a lot on your olate |
| 15:04 |
yboston |
*plate |
| 15:23 |
bshum |
And it doesn't handle things like links. |
| 15:23 |
bshum |
At least, it didn't work for the text block where the other stuff lives now. |
| 15:23 |
|
Dyrcona1 joined #evergreen |
| 15:40 |
kmlussier |
eeevil / goood: I may have asked this question before, but I don't recall the answer. Is bug 1251394 ready for testing or does it still need work? |
| 15:40 |
pinesol_green |
Launchpad bug 1251394 in Evergreen "Metabib Display Fields" (affected: 3, heat: 16) [Wishlist,Triaged] https://launchpad.net/bugs/1251394 - Assigned to Mike Rylander (mrylander) |
| 15:45 |
eeevil |
kmlussier: it's just the backend components, but I think they work. nothing knows how to use them yet, though |
| 15:46 |
kmlussier |
eeevil: Ah, ok. So if we wanted something to be able to use them, it still needs work. |
| 16:27 |
|
rjackson_isl_ joined #evergreen |
| 16:39 |
|
julialima_ left #evergreen |
| 16:59 |
|
mrpeters left #evergreen |
| 17:01 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:31 |
|
chick joined #evergreen |
| 18:07 |
|
ningalls joined #evergreen |
| 19:19 |
|
graced joined #evergreen |
| 00:56 |
|
akilsdonk joined #evergreen |
| 05:04 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:02 |
|
edoceo joined #evergreen |
| 07:14 |
|
hopkinsju joined #evergreen |
| 07:15 |
|
jeff__ joined #evergreen |
| 12:33 |
bshum |
Bleh |
| 12:33 |
Dyrcona |
I'll make a fix and post it to Launchpad. |
| 12:33 |
Dyrcona |
After lunch. |
| 12:34 |
bshum |
Dyrcona++ # thanks for testing that in your system. |
| 12:55 |
|
nhilton joined #evergreen |
| 12:58 |
|
jihpringle joined #evergreen |
| 13:10 |
|
chatley_ joined #evergreen |
| 14:09 |
|
nhilton joined #evergreen |
| 14:12 |
kmlussier |
I'm guessing it's important to those sites using boundaries. |
| 14:13 |
|
mrpeters left #evergreen |
| 14:15 |
tsbere |
kmlussier: At least I saw it as important enough to test and post to launchpad, right? |
| 14:27 |
|
krvmga joined #evergreen |
| 14:36 |
bshum |
Dyrcona++ |
| 14:38 |
|
mrpeters joined #evergreen |
| 15:10 |
bshum |
Again. |
| 15:10 |
dbwells |
bshum: Is metabib.reingest_metabib_field_entries not enough? I need to check to remember what exactly it does and doesn't do. |
| 15:11 |
bshum |
dbwells: I'm unsure. |
| 15:15 |
dbwells |
It's not the right piece. |
| 15:18 |
dbwells |
I think we need metabib.reingest_record_attributes() in this case. Let me see if I can test it out a bit. |
| 15:26 |
dbwells |
bshum: based on my testing, SELECT metabib.reingest_record_attributes(id); is sufficient for this situation. Paste forthcoming... |
| 15:30 |
pastebot |
"dbwells" at 64.57.241.14 pasted "Partial Reingest Addendum For Upgrade Script" (24 lines) at http://paste.evergreen-ils.org/30 |
| 15:35 |
Dyrcona |
Is there a test script floating around to see if Python is working correctly with Evergreen? |
| 15:35 |
Dyrcona |
I did --enable-python 'cause I eventually want to see if I can get constrictor working. |
| 15:35 |
bshum |
dbwells++ |
| 15:35 |
bshum |
I'll tack that on and get the tarball finished to push up to the website |
| 15:56 |
eeevil |
and, berick, do you know of any version restrictions we need to be aware of with the version of angular we're on? |
| 15:58 |
|
nhilton joined #evergreen |
| 16:03 |
jeff |
eeevil: defaulting to jquery CDN and making it reasonably easy to override? |
| 16:03 |
berick |
eeevil: hmm, looks like we should start by testing 2.1 |
| 16:03 |
berick |
"Angular 1.3 only supports jQuery 2.1 or above. jQuery 1.7 and newer might work correctly with Angular but we don't guarantee that. |
| 16:03 |
berick |
" |
| 16:03 |
eeevil |
berick: yep. just saw that. I'm importing 2.1.3 from the cdn |
| 16:04 |
berick |
jeff: I assume we'd want to eventually deploy it ourselves, in the same manner we deploy angular and other deps |
| 16:04 |
eeevil |
jeff: it's just a template ... so, as long as it loads |
| 16:04 |
berick |
.. so we can scrunch it all into a single file |
| 16:06 |
berick |
we'd probably have to deploy it locally for unit tests, too |
| 16:06 |
berick |
i'm sure there's a bower target for jquery, though, so that's easy enough |
| 17:06 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:32 |
|
nhilton_ joined #evergreen |
| 17:54 |
csharp |
Dyrcona: using 14.04 on our DBs but 12.04 everywhere else |
| 17:55 |
Dyrcona |
csharp: Thanks. |
| 21:37 |
Dyrcona |
I also think unwrap_perl suffers from extra recursion. |
| 21:59 |
Dyrcona |
Ah, crazy. |
| 22:00 |
Dyrcona |
Apparently, I am making it into the open-ils.actor.patron.update method, but it is blowing up on addresses. |
| 22:00 |
Dyrcona |
I didn't flesh addresses, 'cause I just wanted to change the name for a test. |
| 22:05 |
Dyrcona |
Interesting. It's blowing up on the user object that it pulled from the database and not the one that I passed in via XML-RPC. |
| 22:08 |
Dyrcona |
Also, unwrap_perl seems to be making a proper Fielmapper::actor:_user object from what I am giving it via XML-RPC. |
| 22:08 |
Dyrcona |
Not as neat as taking what the server gives me, modifying that, and handing it back. |
| 10:54 |
* csharp |
is seeing high RAM on PINES' sip servers and was assuming the fixes for bug 1339190 would help resolve it, but doesn't want to bring on a world of hurt |
| 10:54 |
pinesol_green |
Launchpad bug 1339190 in SIPServer "SIPServer is heavy, not my brother" (affected: 3, heat: 14) [Undecided,Fix committed] https://launchpad.net/bugs/1339190 |
| 10:54 |
csharp |
oh, and we're using a SIPServer of an early 2013 vintage |
| 11:00 |
jeff |
do you have time/resources to run a new SIPServer on an alternate host or alternate port, and test with a small group of SIP clients, adding or removing from the test if/as you run into trouble? |
| 11:00 |
jeff |
i know you'd hate to be too much of a test bed... |
| 11:00 |
csharp |
hmm - that's a thought |
| 11:01 |
csharp |
our testing process is actually asking libraries to connect their devices/third-party services to whichever testing cluster we've set up for the purpose |
| 11:01 |
jeff |
but there are certainly benefits for you (and all) in having the gains of things like the work in that bug, so identifying any new issues would clear the path... |
| 11:02 |
Dyrcona |
Looks like we're not running that fix, yet. |
| 11:02 |
csharp |
but it would answer most of our questions to throw in an upgraded sip server for a day and record what happens |
| 11:36 |
goood |
thanks |
| 11:37 |
goood |
kmlussier: you're using the admin account? |
| 11:38 |
kmlussier |
goood: Yes |
| 11:38 |
goood |
I'm not having that issue. just tested with admin |
| 11:38 |
jboyer-isl |
csharp, There's no news like old news, but I thought I'd pass along that we've been running SIPServer master as of roughly christmas time with Multiplex and it's been good. (I did have to bring back the nightly service restarts, but that's not that big a deal.) |
| 11:39 |
jeff |
jboyer-isl: what made you bring back the nightly service restarts? |
| 11:40 |
jeff |
jboyer-isl: and do you mean just SIPServer, or restarting OpenSRF services on the SIP host also? |
| 11:55 |
|
vlewis joined #evergreen |
| 11:57 |
kmlussier |
Never mind. It seems to be working correctly now. The autocompleting URL probably steered me wrong. |
| 11:58 |
jeff |
9118 Pure Significance Inlet |
| 12:00 |
kmlussier |
OK, one webby mystery solved then. :) |
| 12:00 |
* kmlussier |
resumes testing bug fixes |
| 12:01 |
|
bmills1 joined #evergreen |
| 12:14 |
csharp |
jboyer-isl: thanks for sharing that |
| 12:14 |
csharp |
I'll definitely consider upgrading, at least in a rollback-able way ;-) |
| 12:42 |
bshum |
dbwells: Reading the Launchpad entry, I said I did backport it. So if it's not there, then I guess I screwed something up? |
| 12:43 |
* bshum |
can look more closely when he finishes eating lunch. |
| 12:46 |
kmlussier |
mmorgan: Hooray! :) |
| 12:47 |
dbwells |
bshum: Yes, it was probably just an oversight, but the fact that that piece relied on the other bug gave me pause. I just tested on our live 2.7 install, and am now sure it is needed. I'll push it in when I get back from lunch unless you beat me to it. (same for rel_2_6) |
| 12:48 |
mmorgan |
Forcing https would be good practice, though. |
| 12:57 |
bshum |
dbwells: Well darn, that's an annoying screwup. I'll add that missing commit and then adjust the launchpad ticket to signify that it wasn't actually backported right till now... :( |
| 12:58 |
bshum |
dbwells: Related, I think we've got enough stuff for a good maintenance release soon. |
| 13:13 |
|
mnsri_away joined #evergreen |
| 13:13 |
|
book` joined #evergreen |
| 13:16 |
goood |
kmlussier: I'm going to go ahead and hide it |
| 13:18 |
kmlussier |
goood: OK. I'm about to post to the LP bug the results of our first round of testing on the fixes. |
| 13:35 |
|
kbutler joined #evergreen |
| 13:56 |
|
graced joined #evergreen |
| 13:57 |
|
graced joined #evergreen |
| 16:01 |
collum |
Nope. |
| 16:01 |
collum |
gmcharlt just tweeted. |
| 16:02 |
collum |
I can only go to one conference a year, and this year it's going to be Computers in Libraries. |
| 16:26 |
Dyrcona |
Rollback is great for testing. |
| 17:02 |
|
Kshitij joined #evergreen |
| 17:06 |
|
mrpeters left #evergreen |
| 17:07 |
|
kshitij_2015 joined #evergreen |
| 17:08 |
|
nhilton joined #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 17:11 |
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 |
|
julialima_ left #evergreen |
| 19:32 |
|
remingtron joined #evergreen |
| 19:38 |
|
bmills joined #evergreen |
| 02:42 |
|
Callender joined #evergreen |
| 02:59 |
|
Callender_ joined #evergreen |
| 03:00 |
|
BigRig joined #evergreen |
| 05:14 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:25 |
|
jboyer-isl joined #evergreen |
| 07:42 |
|
dbwells_ joined #evergreen |
| 07:54 |
|
rjackson-isl joined #evergreen |
| 11:58 |
|
jwoodard joined #evergreen |
| 11:59 |
|
bmills joined #evergreen |
| 12:00 |
|
jihpringle joined #evergreen |
| 12:00 |
jeff |
mmorgan: does the template file work in the previous version of the client? i don't remember offhand how tricky that might be in your environment to test. |
| 12:01 |
jeff |
(i'm wondering if there was a change that broke import of previous-version receipt templates, either in some or all circumstances) |
| 12:02 |
|
bmills joined #evergreen |
| 12:04 |
mmorgan |
jeff: Hmm. That's a thought. I'll see if I can find an older client to test it on. |
| 12:05 |
kmlussier |
mmorgan: I could try it in a 2.5 client |
| 12:05 |
jeff |
could also explain why the new client failed to load the stored templates from disk. |
| 12:06 |
jeff |
if you find signs that seem to confirm that theory, the template file that broke could be useful -- especially if it's "only under certain circumstances" kind of thing. |
| 16:17 |
|
bmills joined #evergreen |
| 16:24 |
|
bmills joined #evergreen |
| 16:24 |
RoganH_ |
Quick question - does anyone know off the top of their head if last activity includes SIP activity? |
| 16:24 |
RoganH_ |
(I can go test it of course but feeling lazy.) |
| 16:31 |
kmlussier |
I should know the answer to that question. |
| 16:32 |
mmorgan |
There are sip2 activity types. One for login and one for verify |
| 16:36 |
jeff |
and I think only "verify" is used by current code. |
| 16:52 |
gmcharlt |
@later tell foo you have been eaten by a grue |
| 16:52 |
pinesol_green |
gmcharlt: The operation succeeded. |
| 16:52 |
eeevil |
dbwells++ |
| 16:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:03 |
csharp |
@quote random |
| 17:03 |
pinesol_green |
csharp: Quote #21: "< Dyrcona> Writing software is more fun than working." (added by csharp at 09:29 AM, November 29, 2011) |
| 17:04 |
Dyrcona |
And with that, I'm outta here. |
| 04:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:11 |
|
BigRig_ joined #evergreen |
| 07:46 |
|
rjackson-isl joined #evergreen |
| 07:55 |
|
jboyer-isl joined #evergreen |
| 09:49 |
dbwells |
So, on Google's guide page linked above, looking at the Do/Don't "Travel stream" example, does anyone agree with Google that the raised buttons here are more "heavy" than necessary? |
| 09:50 |
dbwells |
It's about a third of the way down the page. |
| 09:50 |
|
pmurray_away joined #evergreen |
| 09:52 |
phasefx |
dbwells: I don't have a strong opinion there, but I think I'm used to what Google is doing, and I'm very adaptable. Presumably they've done actual user testing (I'd pretty much bet on it) |
| 09:52 |
dbwells |
I'm presuming that as well. |
| 09:53 |
phasefx |
I think the words being verbs and all caps invite them to be interpreted as actions |
| 09:53 |
dbwells |
But even with zillions of dollars, there is always going to be a certain subjectivity to really subtle design choices which is hard to measure, so I'm not going to go all in on Google, either :) |
| 09:55 |
phasefx |
dbwells: and also potential bureaucratic craziness/bias |
| 09:55 |
|
Shae joined #evergreen |
| 09:55 |
phasefx |
I doubt any company is purely rational and numbers driven |
| 09:55 |
jboyer-isl |
My issue with that example (took me a while to find it) is they are comparing completely flat with raised. There’s a level in between, which is just the color border, no shadow. That’s the one I’d prefer in that situation. |
| 09:56 |
jboyer-isl |
phasefx: Google may be as close as can be on that front. (Que stories about the 47 shades of blue A/B testing, etc.) |
| 09:56 |
phasefx |
mmm |
| 09:57 |
gmcharlt |
I also think we can't dismiss that firms like Google, while I do believe that they can and do more actual UX testing... are also under a marketing impetus to refresh their look periodically |
| 09:57 |
phasefx |
as opposed to Yahoo with the CEO changing colors at the last minute :) |
| 10:00 |
dbwells |
jboyer-isl: So do you think you would generally support the idea of a "lighter" button style for cases where button-ness is easily identifiable from context, but a "heavier" style when you need a button to stand out due to placement or generally screen busy-ness? |
| 10:01 |
dbwells |
That question is for everyone else too, of course. |
| 11:56 |
csharp |
hopefully we'll be closer to a browser based client by the time Windows 10 is in common usage, though |
| 11:56 |
mrpeters |
it was working fine |
| 11:56 |
bshum |
mrpeters++ |
| 11:56 |
mrpeters |
i used it for a day to test our standalone debs for Evergreen |
| 11:56 |
bshum |
Testing the future. |
| 11:56 |
mrpeters |
win 10 is going to be pretty solid i think |
| 11:56 |
mrpeters |
may get me to upgrade from win 7 |
| 11:57 |
Jake___ |
Thats great to hear |
| 12:38 |
gmcharlt |
just need somebody to contact me or bshum when they're ready to say go |
| 12:38 |
mrpeters |
i'd probably need someone to tell me when one is needed, and then i'd upload the file and let someone update the downloads page when they update the rest of the clients |
| 12:38 |
gmcharlt |
and for that matter... I'm happen to simply be sent the clients, and I can put them in place |
| 12:59 |
csharp |
gmcharlt: testing your fix now |
| 12:59 |
gmcharlt |
csharp: did you all run into the issue? |
| 12:59 |
* csharp |
recalls running into NOHEADING several months ago |
| 12:59 |
gmcharlt |
snap |
| 13:05 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 13:05 |
gmcharlt |
:) |
| 13:06 |
kmlussier |
Small meeting? :) |
| 13:06 |
gmcharlt |
appears so... |
| 13:06 |
gmcharlt |
#topic Updates |
| 13:06 |
gmcharlt |
#action gmcharlt will install (or verify that it was installed) the libc6 fixes for the "GHOST" vulnerability today on the evergreen-ils.org boxes |
| 13:08 |
gmcharlt |
#action after ALA Midwinter, gmcharlt will get the documentation test VM provisioned |
| 13:08 |
gmcharlt |
kmlussier: any quick updates from you? |
| 13:08 |
kmlussier |
gmcharlt: No, I haven't done anything for the web site this month. |
| 13:08 |
gmcharlt |
I saw that ericar has sent out a query about updated the roster |
| 13:09 |
gmcharlt |
I believe she's on the road today, though |
| 13:28 |
kmlussier |
I would argue that since there wasn't a quorum, the meeting didn't actually take place. ;) |
| 13:28 |
csharp |
one_screenful_meetings++ |
| 13:29 |
tsbere |
kmlussier: Ah, but to discuss things we didn't need a quorum. Just to actually vote on stuff. Our decision was more along the lines of "why discuss things if we can't vote on them anyway?" :P |
| 13:29 |
csharp |
#vote ulitmate power to the web team: Yes |
| 13:30 |
csharp |
er.. ultimate power, even |
| 13:30 |
csharp |
gmcharlt: I tested your branch - signoff branch on the way |
| 13:31 |
bshum |
For fun, http://evergreen-ils.org/irc_logs/evergreen/2011-07/%23evergreen.08-Fri-2011.log was when I thought I had the shortest meeting ever for the community meetings (back when we were doing those). The timestamps put it at14 minutes. So yes, that meeting I missed was shorter :) |
| 13:31 |
bshum |
gmcharlt: Apologies for missing things, I was stuck talking while retrieving my lunch :( |
| 13:32 |
|
vlewis joined #evergreen |
