| 01:48 |
|
beanjammin joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:07 |
|
rlefaive joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:14 |
|
agoben joined #evergreen |
| 09:30 |
pinesol_green |
Launchpad bug 1747664 in Evergreen "Web Client: Cannot batch edit Volume/Call Numbers from Copy Bucket" [Medium,Confirmed] https://launchpad.net/bugs/1747664 |
| 09:31 |
JBoyer |
mmorgan, yes, it should have been removed, and now it is. |
| 09:32 |
mmorgan |
Thanks! |
| 09:32 |
kmlussier |
I'm having a bit of trouble building the web client on master this morning. |
| 09:32 |
kmlussier |
When I run 'npm run test', I'm seeing the following. https://pastebin.com/CA5frnuf |
| 09:34 |
jeff |
you're getting a lawnmower ad? |
| 09:34 |
* jeff |
ducks |
| 09:34 |
jeff |
pastebin-- |
| 09:35 |
jeff |
are each of the ✗ symbols representing a failed test? |
| 09:35 |
jeff |
the only explicit error seems to be: |
| 09:35 |
jeff |
TypeError: undefined is not an object (evaluating 'reportEditScope._mergePaths') in test/unit/egReporter.js (line 174) |
| 09:35 |
jeff |
test/unit/egReporter.js:174:39 |
| 09:36 |
kmlussier |
jeff: Yes, those do represent a failed test. |
| 09:43 |
|
rlefaive joined #evergreen |
| 09:43 |
|
mmorgan joined #evergreen |
| 09:46 |
jeff |
it doesn't look like the automated live tester runs the web client tests. is that right? |
| 09:47 |
bshum |
jeff: I'm pretty sure it should |
| 09:47 |
bshum |
There's at least a linked step there for "Running Evergreen browser client build/test" |
| 09:47 |
jeff |
bah. I scanned/searched for "web" :-) |
| 09:47 |
jeff |
bshum++ |
| 09:48 |
jeff |
looks like it doesn't call out failure: PhantomJS 2.1.1 (Linux 0.0.0): Executed 32 of 32[31m (32 FAILED)[39m[31m ERROR[39m (0.207 secs / 0.202 secs) |
| 09:48 |
kmlussier |
If I ignore the errors and proceed with building the web client, I get a blank screen when trying to access to staff login page. I see this in the console - https://pastebin.com/xr7dbL4y |
| 09:48 |
JBoyer |
I had every single test fail on me last night building 3.1 on U16.04 but I didn't give it much thought since I was just playing around at home and assumed I missed something |
| 09:48 |
kmlussier |
I'm on Ubuntu 14.04 |
| 09:49 |
jeff |
okay then. looks like i probably won't have trouble reproducing this locally, then. :-) |
| 09:49 |
* Dyrcona |
can test it also in a bit. |
| 09:49 |
Dyrcona |
I haven't tested master in a while. I've been focused on 3.0 and our upgrade. |
| 09:50 |
* kmlussier |
tries on 3.0 |
| 09:51 |
jeff |
perhaps unrelated to the current errors, but a conversation the other day caused me to look into how we're handling packages... it doesn't look like we're currently checking in the package-log.json file, and we probably should. |
| 09:51 |
JBoyer |
I did notice an alert to that effect. |
| 09:52 |
jeff |
oh? i didn't know that anything would alert on that. handy, since people often think "that's a generated file, i shouldn't check that in" |
| 09:52 |
jeff |
(but like with bundler and various other things, it's meant to be checked in) |
| 09:53 |
JBoyer |
I think tsc specifically calls out that you should commit package-log.json once it's done it's thing |
| 09:53 |
jeff |
so that package updates and intermediate package updates are intentional and tested before breaking things -- again, possibly completely unrelated to the failed tests at hand, just seemed like a good time to compose my thoughts and mention it here. :-) |
| 09:54 |
Dyrcona |
Maybe it's a problem with fresh installations or with Ubuntu 14.04? |
| 09:54 |
JBoyer |
No, probably npm run. It's been a while since I was messing with taht |
| 09:54 |
Dyrcona |
I just pulled master on Ubuntu 16.04, rand npm update and npm run test and got no errors. |
| 09:54 |
Dyrcona |
s/rand/ran/ |
| 09:59 |
jeff |
er, typo above that i didn't notice. i was referring to package-lock.json. |
| 10:03 |
Dyrcona |
Well, that's a bad name for a file that one should keep around. |
| 10:05 |
Dyrcona |
Oh, nice. While run test reported no problems, my web staff login page comes up blank. |
| 10:06 |
Dyrcona |
Lots of failure to instantiate module errors in the console. Looks like it is pulling in AngularJS 1.7. |
| 10:07 |
bshum |
Well that sounds bad |
| 10:07 |
* Dyrcona |
recalls someone suggesting we should "pin" the AngularJS version recently. |
| 10:11 |
kmlussier |
Dyrcona: Yes, that was the first error in my Console messages too. |
| 10:12 |
Dyrcona |
Then the URI for the error string goes to an AngularJS 1.7.0 reference for injector module error. |
| 10:12 |
Dyrcona |
Well, I guess it's the error documentation reference. |
| 10:13 |
Dyrcona |
kmlussier: So, looks like the same problem even though tests passed for me. |
| 10:13 |
kmlussier |
Dyrcona: I guess that's enough confirmation to file a bug, then. |
| 10:14 |
jeff |
Dyrcona: if you're unfamiliar with the concept, this does a decent job of explaining package-lock.json: https://docs.npmjs.com/files/package-locks |
| 10:15 |
jeff |
in general, it can be summed up as: if you use and commit package-lock.json, you will reduce the number of times that things break unexpectedly due to the release of a new version of one of your dependencies. :-) |
| 10:15 |
Dyrcona |
Looking at my scrollback, npm update definitely pulled in AngularJS 1.7.0, and changing package.json as bshum suggested pulls in AngularJS 1.6.10. |
| 10:16 |
Dyrcona |
jeff: I don't know that much about AngularJS, Angular, or Node.js. I know the barebones to work on the code. I haven't gotten into the guts. |
| 10:16 |
Dyrcona |
Frankly, I'd rather not have to. :) |
| 10:18 |
Dyrcona |
Oh, now, my tests fail. :( |
| 10:18 |
Dyrcona |
After doing what bshum suggested and doing npm update followed by npm run test the test fail. |
| 10:25 |
bshum |
Dyrcona: If I edit my package.json file to pin the version, then removed my node_modules and build dirs |
| 10:25 |
bshum |
Then ran new npm install / npm run build-prod / npm run test |
| 10:25 |
bshum |
And that all seems to pass the tests for me |
| 10:26 |
bshum |
Well, npm update, then npm install, etc. |
| 10:26 |
Dyrcona |
I didn't go through all of those steps because a) ignorant and b) lazy. |
| 10:29 |
bshum |
And voila, happy new test VM with master + that tiny tweak to pin to AngularJS 1.6 |
| 10:29 |
bshum |
Well, Ubuntu 16.04 anyways |
| 10:31 |
kmlussier |
I can build a branch and test it on 14.04. |
| 10:32 |
Dyrcona |
npm run test still fails for me after npm run build. |
| 10:33 |
|
Christineb joined #evergreen |
| 10:33 |
Dyrcona |
And with npm run build-prod. |
| 10:34 |
|
bdljohn joined #evergreen |
| 10:54 |
bshum |
We'll probably rip it all apart soon anyways |
| 10:54 |
kmlussier |
bshum: And when you say all, you mean everything, not just the 1.6.7 stuff, right? |
| 10:55 |
Dyrcona |
I'll make a followup/signoff branch. |
| 10:57 |
bshum |
kmlussier: That's what I want to say, but I don't know if there's any reason we haven't been checking the versions specified in the file and making sure all the deps are up to date. |
| 10:57 |
bshum |
Like I'd worry that hotkeys being ^ all this time, might break if we're expecting some new hotkey version than the one specified, etc. |
| 10:57 |
bshum |
So maybe we do want some expert advice from berick/gmcharlt/miker on the deps |
| 10:57 |
bshum |
Course it's easy enough to test what'll happen either way :D |
| 10:58 |
kmlussier |
bshum: Well, sure, it's easy to test what happens now, but not what happens in the future when version change. |
| 11:00 |
jeff |
if anyone has a recent working-not-broken package-lock.json file lying around, i'd be interested in getting a copy of it. |
| 11:03 |
bshum |
jeff: Where does that file get generated into? |
| 11:04 |
Dyrcona |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1771371-pin-to-angular-js-1-6 |
| 11:04 |
Dyrcona |
For anyone who wants to test the follow-up commit. |
| 11:05 |
Dyrcona |
jeff: I can't find one on my test vm. |
| 11:05 |
kmlussier |
And the first commit works! bshum++ Dyrcona++ jeff++ |
| 11:06 |
bshum |
Yeah neither can I. I found a package-lock.json.#date# one, but it's empty |
| 11:06 |
bshum |
No other files with a similar name in the whole VM |
| 12:21 |
gsams |
I've run a few tests and it takes up to a minute and a half for 50 items, which I'm not sure how that ranks for folks, but I feel it's pretty slow. |
| 12:21 |
miker |
jeffdavis: yay! I'll be testing that here, too. thanks for digging into it! |
| 12:22 |
mmorgan |
gsams: Have your test items had several renewals already? |
| 12:22 |
gsams |
My tests have had none and a few. I've run multiple tests on the same account/items |
| 12:25 |
gsams |
It didn't seem to make any difference either way. |
| 12:26 |
|
jihpringle joined #evergreen |
| 12:27 |
berick |
yay, just updated my ang5 demo site to ang6. https://35.186.179.218/eg2/staff/login Going to post install docs to the wiki soon and share to dev list. |
| 12:28 |
Dyrcona |
Well, a lot goes with a single renewal, so multiply that by 50 and there you go. |
| 12:53 |
pinesol_green |
kmlussier: Karma for "comcast" has been increased 0 times and decreased 10 times for a total karma of -10. |
| 13:13 |
jeffdavis |
We're upgrading to 3.1 this weekend. Just in time for Bug Squashing Week! :) |
| 13:22 |
JBoyer |
jeffdavis, I'll be looking forward to seeing how things go for you since we decided to wait until the first week of June. :) |
| 13:49 |
kmlussier |
Oh fun! UI wonkiness on a test system with 5 different patches with no obvious candidate as to which one is causing the problem. |
| 13:49 |
kmlussier |
jeffdavis: Best wishes on the upgrade! |
| 13:57 |
* dbs |
is also looking forward to seeing how the jeffdavis upgrade goes |
| 13:59 |
|
jvwoolf1 joined #evergreen |
| 14:15 |
jeffdavis |
Would it be worth pinning AngularJS to the latest 1.6 release (1.6.10) rather than 1.6.7? |
| 17:01 |
|
lsach left #evergreen |
| 17:01 |
|
mmorgan left #evergreen |
| 17:15 |
kmlussier |
Calling 1110 |
| 17:27 |
pinesol_green |
[evergreen|Galen Charlton] LP#1756912: restore display of copy counts for preferred library - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3e311c3> |
| 17:27 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1756912: Stamping upgrade script for add preferred lib to unapi feeds - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1dab670> |
| 18:30 |
|
jvwoolf joined #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:21 |
|
jvwoolf joined #evergreen |
| 02:27 |
|
gsams__ joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:39 |
|
rlefaive joined #evergreen |
| 07:43 |
|
collum joined #evergreen |
| 14:31 |
jeffdavis |
Sorry, recreate which aspect exactly? |
| 14:34 |
miker |
I mean, does that happen everywhere, or just on some workstations that attempt to use offline? |
| 14:35 |
miker |
IOW, could it be bad IndexedDB data in some browser instances? |
| 14:38 |
jeffdavis |
Myself and at least two other folks here are seeing it on separate workstations (all using Chrome on Windows or Ubuntu, connecting to the same test server). Clearing cache and local data doesn't help, the same org units are consistently missing from that one dropdown. |
| 14:41 |
jeffdavis |
I added some console logging to the reconstituteTree function in lovefield.js. Seems like the missing org units are in the list when it is initially retrieved by getListFromOfflineCache, but they are missing after the list is processed. |
| 14:41 |
jeffdavis |
I'll share a patch to show what I mean, one sec |
| 14:45 |
pastebot |
"jeffdavis" at 64.57.241.14 pasted "lovefield.js reconstituteTree logging" (22 lines) at http://paste.evergreen-ils.org/4436 |
| 14:50 |
jeffdavis |
the first log entry there, "log: %o", shows missing org units which do not appear in the second log entry, "tree: %o" |
| 15:03 |
|
abowling joined #evergreen |
| 17:49 |
Bmagic |
I see, ok. So how do I complete an invoice? From the PO interface, I can see "view invoices" and that pops a new tab with hardcoded search critera to the linitem id but the results are not clickable |
| 17:49 |
Bmagic |
I suppose I need to click on "View Invoices" at the top of the interface |
| 17:51 |
Bmagic |
berick++ |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:43 |
|
abowling left #evergreen |
| 19:50 |
|
rlefaive joined #evergreen |
| 20:41 |
jeffdavis |
I almost understand the issue with bug 1770478 but trying to put it into words is not easy |
| 20:41 |
pinesol_green |
Launchpad bug 1770478 in Evergreen "Web Client: Offline Issue Affects System where child orgs have lower ID number than parent" [High,Confirmed] https://launchpad.net/bugs/1770478 |
| 20:41 |
jeffdavis |
the filter() call is indeed the source of our problem |
| 20:41 |
jeffdavis |
we iterate through the list of org units; for each entry in the list we call filter() on the full list |
| 20:42 |
jeffdavis |
filter() in turn iterates through the full list in order |
| 20:43 |
jeffdavis |
let's say item.id = 20 |
| 20:44 |
jeffdavis |
as filter() works through the list, it does this test on each org unit: kid[parent_field]() == item[pkey]() |
| 20:44 |
jeffdavis |
for org units where id < 20, that test will always return false |
| 20:45 |
jeffdavis |
because, roughly speaking, kid[parent_field]() is a function and item[pkey]() is not |
| 20:46 |
jeffdavis |
but where id >=20, kid[parent_field]() is an actual value rather than a function, so it will return the correct value (true if the parent_ou is 20, false otherwise) |
| 20:48 |
pastebot |
"jeffdavis" at 64.57.241.14 pasted "LP#1770478 console logging 3 - filter check" (13 lines) at http://paste.evergreen-ils.org/4478 |
| 20:49 |
pastebot |
"jeffdavis" at 64.57.241.14 pasted "LP#1770478 console logging 3 - filter check (output)" (8 lines) at http://paste.evergreen-ils.org/4479 |
| 20:50 |
jeffdavis |
I'm sure I'm not explaining the test failure quite right but the above console log output hopefully shows what I mean |
| 20:51 |
jeffdavis |
the extra catch is that the org unit list is string-sorted, not numeric-sorted |
| 20:52 |
jeffdavis |
so it would be more accurate to say that the filter test always returns false if id::text < '20'::text (199 is always false, 3 is the correct value depending on its parent_ou) |
| 20:54 |
jeffdavis |
anyway, that's the best I can do for today |
| 20:54 |
jeffdavis |
@monologue |
| 20:54 |
pinesol_green |
jeffdavis: Your current monologue is at least 5 lines long. |
| 20:54 |
* jeffdavis |
shakes fist at pastebot |
| 21:45 |
|
beanjammin joined #evergreen |
| 03:44 |
|
jaswinder joined #evergreen |
| 04:38 |
|
beanjammin joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
agoben joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:35 |
|
rlefaive joined #evergreen |
| 08:41 |
|
rlefaive joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:56 |
csharp |
after a recent re-install of master on my testing server, I'm seeing several instances of this issue: https://stackoverflow.com/questions/41281515/possibly-unhandled-rejection-in-angular-1-6 and things like the "Item Status" view aren't loading |
| 08:57 |
csharp |
since I don't hear anyone else talking about it, I'm wondering if it's just me, but my test server is kind of dead in the water until I resolve this |
| 08:57 |
csharp |
from the symptoms, it looks like issues common to upgrading to angular 1.6 |
| 09:01 |
csharp |
hmm - normally I wouldn't celebrate something like this, but I just hit a white screen - hooray! |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:06 |
|
rlefaive_ joined #evergreen |
| 09:06 |
JBoyer |
csharp, Maybe we'll have to start pinning Angular versions to get semi-stable installations? :/ |
| 10:42 |
|
rlefaive joined #evergreen |
| 11:19 |
Dyrcona |
JBoyer | jeff: Turns out to be easy enough for my purposes: https://pastebin.com/per3f5QY |
| 11:24 |
JBoyer |
Dyrcona, that looks like that may be pretty handy. I was thinking about the last time someone asked about incoming payments for overdue vs lost which I absolutely hated. |
| 11:43 |
csharp |
JBoyer: I can confirm that your FF branch works fine (using web-ext) on my Fedora workstation - planning to test Windows in a VM next |
| 11:44 |
JBoyer |
Woo. |
| 11:44 |
JBoyer |
I can also toss out some anecdata that Hatch works fine with Java 10 since I forgot I had it installed on my laptop while fighting with this. |
| 11:45 |
csharp |
good |
| 12:46 |
|
mmorgan joined #evergreen |
| 14:16 |
|
yboston_ joined #evergreen |
| 14:17 |
|
gsams__ joined #evergreen |
| 14:36 |
pinesol_green |
[evergreen|Jane Sandberg] LP1766712: Add Scrollbar to Patron Search Permission Group Field - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=06fda6a> |
| 14:54 |
|
tlittle joined #evergreen |
| 15:38 |
|
mmorgan1 joined #evergreen |
| 16:02 |
pinesol_green |
[evergreen|Bill Erickson] LP#1740537 Transit dialog showing wrong branch - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0b3b42b> |
| 16:08 |
|
jaswinder joined #evergreen |
| 16:14 |
|
jaswinder joined #evergreen |
| 16:15 |
|
mmorgan joined #evergreen |
| 17:06 |
|
Dyrcona joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:39 |
|
abowling left #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:42 |
|
gsams__ joined #evergreen |
| 18:52 |
|
akilsdonk_ joined #evergreen |
| 19:59 |
|
JBoyer-alt joined #evergreen |
| 02:15 |
|
jonadab joined #evergreen |
| 04:39 |
|
abowling joined #evergreen |
| 06:20 |
|
jaswinder joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:37 |
|
kmlussier joined #evergreen |
| 07:47 |
|
rlefaive joined #evergreen |
| 08:08 |
|
rlefaive_ joined #evergreen |
| 10:53 |
kmlussier |
jeff: Thank you! Now I won't be able to shift responsibility for typos to anyone but me. |
| 10:54 |
mmorgan |
kmlussier: You can always blame the cat |
| 10:54 |
Dyrcona |
@blame the cat |
| 10:54 |
pinesol_green |
Dyrcona: the cat tests their code on the LIVE SERVERS, then blames the user. SAD! |
| 10:55 |
kmlussier |
If 'tests their code' = 'walks on keyboards' that is indeed a true statement. |
| 10:57 |
|
Christineb joined #evergreen |
| 11:02 |
|
yboston joined #evergreen |
| 11:19 |
|
abowling1 joined #evergreen |
| 11:51 |
|
khuckins joined #evergreen |
| 12:03 |
|
jaswinder joined #evergreen |
| 12:04 |
|
jihpringle joined #evergreen |
| 12:17 |
* csharp |
hires a cat to test his code |
| 12:21 |
bshum |
"Everybody wants to be a cat... because a cat's the only cat who knows where it's at..." /singsong |
| 12:25 |
kmlussier |
bshum++ |
| 12:25 |
* kmlussier |
will now have that song stuck in her head all day. |
| 16:06 |
|
jvwoolf joined #evergreen |
| 16:30 |
|
jvwoolf1 joined #evergreen |
| 16:38 |
|
sandbergja joined #evergreen |
| 16:50 |
jeffdavis |
Is anyone else seeing apache2-websockets processes maxing out CPU? |
| 16:52 |
jeffdavis |
I believe we've fixed instances of this before. I'm seeing it in production on 2.12, not so far in our 3.1 test environment. |
| 16:58 |
|
khuckins_ joined #evergreen |
| 17:01 |
|
sandbergja joined #evergreen |
| 17:02 |
|
mmorgan left #evergreen |
| 17:44 |
jeffdavis |
aha, thanks miker |
| 18:11 |
|
abowling1 joined #evergreen |
| 18:30 |
|
abowling joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:33 |
|
beanjammin joined #evergreen |
| 19:58 |
csharp |
6f1f2a4f |
| 19:58 |
pinesol_green |
csharp: [evergreen|Mike Rylander] LP#1676608: copy alert and suppression matrix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6f1f2a4> |
| 00:41 |
|
beanjammin joined #evergreen |
| 02:13 |
|
jaswinder joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:14 |
|
jaswinder joined #evergreen |
| 07:29 |
|
tlittle joined #evergreen |
| 07:51 |
|
kmlussier joined #evergreen |
| 09:39 |
kmlussier |
abneiman: That's a thought. Thanks! |
| 09:47 |
miker |
kmlussier / abneiman: I'm pretty sure 260b is included because I asked a PINES cataloger "hey, if there's just no author field in a record, what should we include to disambiguate works with the same title?" back in 2004-ish |
| 09:49 |
kmlussier |
miker: In that case, then, we probably should include the 264b. But will the system grab the 700 author before it gets to 260? In my experience, it goes through the fields in the order they're on the MARC record. |
| 09:51 |
miker |
the intent is to get them in xpath order. it /used/ to do that, but I admit I haven't tested since we moved to the built-in xpath() function (in my defence, that's because it's the same code, just in core PG rather than an extension -- both versions use libxml2) |
| 09:52 |
miker |
it iterates through "|" separated expessions, executing each and returning the set returned by each. then we just take the first that comes out of the function |
| 09:53 |
miker |
also, +1 to 264b (or any other additions -- /still/ not a cataloger ;) ) |
| 09:53 |
kmlussier |
miker: It's been a couple of years since I've looked at it. I'll test it further to see if I can confirm what the current behavior is. |
| 09:54 |
kmlussier |
Also not a cataloger, though I did head a tech services department once for about a year. |
| 09:59 |
|
Christineb joined #evergreen |
| 10:08 |
csharp |
@quote search parties |
| 10:08 |
pinesol_green |
csharp: 1 found: #46: "<_bott_> I am not a cataloger, but I speak..." |
| 12:06 |
berick |
that sounds promising.. |
| 12:07 |
csharp |
so after removing the "allowed_origins" section and adding "allowed_extensions", it sees my printer |
| 12:07 |
berick |
nice! |
| 12:07 |
csharp |
and no more barfing in the background page |
| 12:12 |
csharp |
something's still not right because test print stuff is non-responsive, but I need a lunch break |
| 12:12 |
csharp |
might be a good thing to finish at the hackfest |
| 12:16 |
Bmagic |
charp++ |
| 12:16 |
Bmagic |
csharp++ even |
| 12:16 |
Bmagic |
speaking of karma |
| 12:17 |
berick |
csharp++ # indeed |
| 12:27 |
|
jihpringle joined #evergreen |
| 12:49 |
|
collum joined #evergreen |
| 13:07 |
csharp |
the print message successfully makes it to hatch.sh so I think my problem is at the OS level |
| 13:07 |
csharp |
I've had not-fun printing issues on Fedora for the last few releases |
| 13:08 |
csharp |
so, an apparently successful test of Firefox hatch! |
| 13:10 |
berick |
yay |
| 13:10 |
alynn26_away |
resistance++ |
| 13:20 |
|
jaswinder joined #evergreen |
| 13:30 |
|
jaswinder joined #evergreen |
| 13:43 |
jeffdavis |
csharp: did you force-push an update to user/csharp/lp1746300_fix_circ_counts_item_status_details a few days ago? |
| 13:43 |
jeffdavis |
also, |
| 13:43 |
jeffdavis |
csharp++ # hatch ffx testing |
| 13:49 |
jeff |
kmlussier, rhamby: if you didn't know, "sched" seems to be spamming twitter on your behalf. If you did know, well... then "spam" might be the wrong term. |
| 13:50 |
rhamby |
jeff: I sent out a single one from it, is it sending more than that? |
| 13:50 |
kmlussier |
jeff: Yes, you have to intentionally share to get sched to post to twitter. |
| 13:56 |
csharp |
jeffdavis: I had trouble creating the for loop that dbwells recommended from the XUL code and added some additional logic for handling a null value for one of the two possible rows from circbyyr |
| 13:57 |
csharp |
almost certainly not the most elegant approach, so if someone wants to correct it, I'm totally good with that (bug 1746300) |
| 13:57 |
pinesol_green |
Launchpad bug 1746300 in Evergreen "Item Status screen - Total Circs Current and Prev Incorrect" [Undecided,Confirmed] https://launchpad.net/bugs/1746300 - Assigned to Jeff Davis (jdavis-sitka) |
| 13:57 |
jeffdavis |
I think I ran into the latter case when testing last week, I'll try out the updated branch |
| 13:58 |
csharp |
cool |
| 13:58 |
csharp |
please let me know if you see trouble |
| 14:03 |
csharp |
found while exploring FF addon information: https://addons.mozilla.org/en-US/firefox/addon/the-laser-cat/?src=hp-dl-promo |
| 16:25 |
kmlussier |
miker: I'm hoping you can assist me with something. I'm logging long-running queries, well, actually, all sql queries so that I can grab the core query for a search. Things look different in 3.1. Could you tell me where I would find the core query in this paste? https://pastebin.com/E4aHbxHd |
| 16:25 |
kmlussier |
I thought it might be somewhere around "Completed canonicalized SEARCH IS", but I'm mostly just seeing queries for facets and for highlighting. |
| 16:30 |
* csharp |
closes out the day by mentioning my linked branch on bug 1731922 |
| 16:30 |
pinesol_green |
Launchpad bug 1731922 in Evergreen "Firefox add-on for Hatch" [Wishlist,Confirmed] https://launchpad.net/bugs/1731922 |
| 17:04 |
|
mmorgan left #evergreen |
| 17:49 |
|
jaswinder joined #evergreen |
| 18:24 |
|
jaswinder joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:57 |
|
jaswinder joined #evergreen |
| 21:35 |
|
jaswinder joined #evergreen |
| 01:50 |
|
jaswinder joined #evergreen |
| 05:50 |
|
jaswinder joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:52 |
|
agoben joined #evergreen |
| 06:52 |
|
JBoyer joined #evergreen |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 10:26 |
|
dwgreen joined #evergreen |
| 10:27 |
Bmagic |
Is there a trick to running reports on a postgres replica? Sometimes we are getting "The row dissappeared" for long running reports |
| 10:34 |
|
bwicksall joined #evergreen |
| 10:38 |
bwicksall |
What version of Node.js should I have for Evergreen 3.0? Back when I setup my test server LTS was 6.X and now it is 8.11.1. I'm having some odd issues in the web staff client. |
| 10:38 |
JBoyer |
Bmagic, where are you seeing that and is it a postgres error or something from evergreen? |
| 10:38 |
Bmagic |
It's a postgres error that surfaces in the error message in the reporter GUI |
| 10:39 |
Bmagic |
FATAL: terminating connection due to conflict with recovery |
| 10:47 |
* bshum |
thinks we should revise that step |
| 10:47 |
bwicksall |
Yes, I'm following 4.1.1. |
| 10:48 |
bwicksall |
I'll try to roll back |
| 10:48 |
bshum |
6.14.1 should be fine, in theory. I think I tested up through 6.13 when I was poking around |
| 10:49 |
bshum |
But the makefile script is supposed to download 6.11.3 specifically |
| 10:49 |
|
kmlussier joined #evergreen |
| 10:49 |
bshum |
Which is considered "stable" from testing |
| 10:49 |
bwicksall |
Ok, se here is my problem. On the patron registration we are using org unit settings to hide alias. It will not hide on my test server. |
| 10:50 |
bwicksall |
Works find on my Equinox hosted live server |
| 10:50 |
JBoyer |
Bmagic, Yeah, I think those are what I was thinking of, but I didn't think hot_standby was necessary. May be. Setting those slightly longer than the timeout on your reports queries should prevent them from causing too much trouble. |
| 10:54 |
kmlussier |
Does anyone know why we include 260b in the author bit for the biblio fingerprint? |
| 10:55 |
bshum |
bwicksall: Hard to say then, might be code differences between versions (you said 3.0, but which .x point release is it) and whatever Equinox is running for your other instance |
| 12:44 |
jeff |
ah, there it is! |
| 12:44 |
kmlussier |
I'm guessing it would get used a lot with videos. But if it does make sense to continue to include the publisher, we would need to add the 264b |
| 12:44 |
dbs |
kmlussier: ours has the 260$b at the end |
| 12:45 |
kmlussier |
dbs: In the configuration? Yes, ours does too, but when I tested it a few years ago, the order in the config didn't seem to matter. |
| 12:45 |
dbs |
oooh, right, I see |
| 12:45 |
kmlussier |
Unfortunately, I don't have much time to look at it more closely now. I also found a record that made me think authors from the 700$a weren't being added at all. |
| 12:46 |
kmlussier |
Maybe something to explore further at the hackfest! :) |
| 16:59 |
|
jaswinder joined #evergreen |
| 17:02 |
|
mmorgan1 left #evergreen |
| 17:45 |
|
jaswinde_ joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 21:42 |
|
jaswinder joined #evergreen |
| 22:13 |
|
jaswinder joined #evergreen |
| 22:55 |
|
jaswinder joined #evergreen |
| 00:12 |
|
jaswinder joined #evergreen |
| 00:43 |
|
bshum joined #evergreen |
| 02:48 |
|
jaswinder joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:43 |
|
kmlussier joined #evergreen |
| 07:11 |
|
troy__ joined #evergreen |
| 07:14 |
kmlussier |
@coffee [someone] |
| 09:29 |
jaswinder |
thanks csharp! I will check out Actor class |
| 09:35 |
|
yboston joined #evergreen |
| 09:44 |
|
mmorgan1 joined #evergreen |
| 09:56 |
Bmagic |
I am finding that an email address that contains a period before the @ sign is ending up in the from address missing the ending domain name. for example: test.from from.com ends up being test.from from |
| 09:56 |
bshum |
Stompro: That's an interesting find about the auditor.biblio_record_entry_history that you noted on that general email about upgrading |
| 09:57 |
bshum |
I think I've never noticed it because I'm building from scratch and the auditor function bases its creation on whatever exists at the time, so the new columns are fine for me in my test database. But I guess something should account for those new columns on upgraded systems :\ |
| 09:58 |
|
Christineb joined #evergreen |
| 10:01 |
Stompro |
bshum, there does seem to be a function that corrects the auditor tables so they match the source tables, so it probably is a simple fix... although I don't know how long it takes to add columns to huge tables, so it might be a more of a problem. |
| 10:02 |
bshum |
Stompro: I don't have a large database to test on anymore, but let us know what you discover :) |
| 10:02 |
bshum |
Stompro++ |
| 10:03 |
Stompro |
bshum, I also just noticed that the auditor table trigger is included in the ones to remove for the visibility update, so I guess that answers my question, it is something that is done. |
| 10:05 |
|
beanjammin joined #evergreen |
| 10:14 |
|
stephengwills left #evergreen |
| 11:04 |
|
idjit joined #evergreen |
| 11:09 |
|
tlittle joined #evergreen |
| 11:16 |
|
rlefaive joined #evergreen |
| 11:21 |
jaswinder |
I need to authenticate a user in test. I think to pass in the type of user. How do I determine the type of user from db? |
| 11:22 |
jaswinder |
for instance, staff, opac, etc |
| 11:28 |
|
eby joined #evergreen |
| 11:51 |
|
beanjammin joined #evergreen |
| 11:54 |
|
jwoodard joined #evergreen |
| 15:18 |
Bmagic |
jeff: no |
| 15:20 |
Bmagic |
during this research, I am a bit confused about the variable "lib" - it doesn't seem like it should work but apparently id does |
| 15:20 |
Bmagic |
the context is action.hold_request which doesn't contain a column "lib" |
| 15:20 |
jeff |
Bmagic: can you pastebin the template somewhere? if you hardcode the From: address as a test (in a test system / test template / whatever) do you see the same behavior? |
| 15:21 |
jeff |
Bmagic: generally you would have something in the template that sets lib, though the stock hold available notice doesn't do that. |
| 15:24 |
Bmagic |
so the lib variable (from the default template) is null and therefore skipped? Weird. The template does not set that variable |
| 15:25 |
jeff |
not seeing the weird part. the stock template neither defines nor uses 'lib'. i'm wondering what your template looks like. |
| 15:27 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "sample template" (6 lines) at http://paste.evergreen-ils.org/3074 |
| 17:06 |
|
mmorgan left #evergreen |
| 17:21 |
|
jaswinder joined #evergreen |
| 18:29 |
|
jaswinder joined #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:09 |
|
jaswinder joined #evergreen |
| 20:14 |
|
jaswinder joined #evergreen |
| 20:23 |
|
jaswinder joined #evergreen |