00:10 |
|
yboston joined #evergreen |
01:33 |
|
beanjammin joined #evergreen |
06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:05 |
|
agoben joined #evergreen |
07:13 |
|
rjackson_isl joined #evergreen |
07:40 |
|
bdljohn joined #evergreen |
09:48 |
rjackson_isl |
bringing back the "snap, crackle and pop" to your listening enjoyment! |
09:48 |
* idjit |
is reminded of this wallpaper https://i.imgur.com/cMn17t9.png |
09:49 |
rjackson_isl |
ah yes, 9 volt transister radios - those were the days... |
09:52 |
Dyrcona |
kmlussier: Do you want me to load the branch from bug 1741997 somewhere you can test it with our data? |
09:52 |
pinesol_green |
Launchpad bug 1741997 in Evergreen "additional browse improvements" [Medium,Confirmed] https://launchpad.net/bugs/1741997 |
09:53 |
* Dyrcona |
times his work with his music....When the Dire Straits collection finishes, it will be time to call in for the meeting. |
09:57 |
pinesol_green |
[evergreen|Bill Erickson] LP#1639022 Webstaff convert change to credit - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=835bac8> |
10:04 |
kmlussier |
Dyrcona: Yes, please. I'm having authority issues on my own VMS, and I'm not quite sure why. Since I know cross-references are displaying on your servers, I'm hoping the patch could just be applied and I could see if it fixes the specific bugs. |
10:04 |
Dyrcona |
Ok. I'll add it to testing.cwmars.org. |
10:05 |
Dyrcona |
Looks like it is currently at 3.0.3. |
10:13 |
* Dyrcona |
upgrades it to 3.0.7. |
10:14 |
|
jwoodard joined #evergreen |
10:16 |
|
beanjammin joined #evergreen |
10:18 |
Dyrcona |
kmlussier: Do you want me to do anything in particular after installing the branch, like running the linker or anything like that? |
10:19 |
kmlussier |
Dyrcona: I don't think the linking is required, but I'm not sure about an authority reingest. gmcharlt: do you know if a reingest is required to test bug 1741997? |
10:19 |
pinesol_green |
Launchpad bug 1741997 in Evergreen "additional browse improvements" [Medium,Confirmed] https://launchpad.net/bugs/1741997 |
10:20 |
kmlussier |
Well, the linking is required to show the cross-references. I should say I don't think re-linking is required. |
10:21 |
gmcharlt |
linking is required, yes, if it hasn't already been done; reingest should not be |
01:36 |
|
beanjammin joined #evergreen |
05:26 |
|
beanjammin joined #evergreen |
06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:59 |
|
agoben joined #evergreen |
07:12 |
|
rjackson_isl joined #evergreen |
07:37 |
JBoyer |
jeffdavis++ |
08:43 |
|
remingtron joined #evergreen |
08:46 |
|
mmorgan joined #evergreen |
09:07 |
|
bos20k joined #evergreen |
09:07 |
bshum |
@later tell kmlussier https://i18n.evergreener.net -- master (as of this morning) demo server with i18n enabled - I'll leave it in place for the week for testing |
09:07 |
pinesol_green |
bshum: The operation succeeded. |
09:19 |
|
dickreckard joined #evergreen |
09:19 |
dickreckard |
uhm the documentation to upgrade to 3.1 links to some old documentation on how to update to 2.12 |
13:08 |
|
rlefaive joined #evergreen |
13:09 |
|
collum_ joined #evergreen |
13:19 |
|
eady joined #evergreen |
13:24 |
csharp |
berick: testing bug 1727557... the file appears to download fine but when I enter a patron barcode from the blocklist, firefox dies - I haven't tried in Chrome yet |
13:24 |
pinesol_green |
Launchpad bug 1727557 in Evergreen "Web Client: Download Block List causes unresponsive page with large file" [High,Confirmed] https://launchpad.net/bugs/1727557 - Assigned to Dawn Dale (ddale) |
13:25 |
* csharp |
tries Chrome |
13:30 |
csharp |
same behavior in Chrome |
13:35 |
csharp |
yeah - trying to navigate the DB tree in FF makes it die |
13:37 |
csharp |
ok - Chrome is at least letting me look |
13:37 |
csharp |
yes, I see valid data in the offline blocks table |
13:38 |
berick |
does the browser differentiate between the different block types? |
13:39 |
berick |
i notice lots of dupes in my test file |
13:39 |
berick |
dupe barcodes, that is |
13:39 |
csharp |
finally got FF to stay open - seeing valid data there too now |
13:40 |
csharp |
the browser shows L, D, etc. under "reason" |
13:40 |
csharp |
let me look for dupes |
14:04 |
pinesol_green |
JBoyer: Unlikely. |
14:05 |
JBoyer |
Sorry kmlussier, that sounds pretty ironclad. ;) |
14:07 |
kmlussier |
JBoyer: I'm still shooting for Friday afternoon. Maybe pinesol_green knows of some workplace crisis that will deter me. |
14:09 |
csharp |
kmlussier: this is a bad week for me too - also, I usually don't get much direct squashing done because I'm helping terran and others get patches installed on test servers (which I'm happy to do) |
14:09 |
berick |
@who will blast [band] to get kmlussier pumped for bug squashing! |
14:09 |
pinesol_green |
yboston will blast All The Jeffs to get kmlussier pumped for bug squashing. |
14:09 |
berick |
all the other Jeffs with their pumped up kicks... |
15:22 |
dbs |
mrca_vlist_idx failed because operator class "evergreen.gin__int_ops" does not exist for access method "gin" - heh |
15:22 |
* dbs |
recently picked up some nice gin from our local https://crosscutdistillery.ca/ |
15:23 |
dbs |
dump method was: pg_dump --cluster <dbcluster> -U <dbuser> -i -Fd -Z 9 -f <dumpfile> --serializable-deferrable <dbname> |
15:35 |
jeff |
Yeah. Maybe in a previous chain of events CREATE EXTENSION intarray; was called without an explicit schema, and the default object creation schema thanks to search_path was "evergreen"... then when it came time to CREATE FUNCTIOn metabib.compile_composite_attr, the search path no longer contained "evergreen" and someone modified the function definition to reference evergreen.query_int... |
15:37 |
jeff |
(haven't tested, and not sure that I can test that theory) |
15:37 |
jeff |
I'll take a stab at writing up some of the challenges and known issues and maybe some recommendation for devs and admins. |
15:38 |
jeff |
Seems worthwhile. |
15:39 |
|
mmorgan joined #evergreen |
15:39 |
dbs |
That would be awesome |
15:45 |
jeff |
I've also been thinking again about how best to audit existing databases for issues including things like "oops, we ended up with two versions of this function in different schemas" |
15:46 |
jeff |
...maybe in a few days. :P |
15:47 |
* dbs |
heads home |
15:56 |
pinesol_green |
[evergreen|Galen Charlton] LP#1497322: add Perl live_t regression and unit tests for patron searching - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=28f155f> |
15:56 |
pinesol_green |
[evergreen|Jason Boyer] LP14973322: Search for Users by Profile - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ce419b5> |
15:56 |
pinesol_green |
[evergreen|Galen Charlton] LP#14973322: (follow-up) allow profile-only patron searches - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1e1e83a> |
16:53 |
jeffdavis |
Is it reasonable to think that bug 1765444 might be the proximate cause of open-ils.cat NOT CONNECTED errors? |
16:53 |
pinesol_green |
Launchpad bug 1765444 in Evergreen "webstaff MARC editor can spam requests for fixed field metadata" [Medium,New] https://launchpad.net/bugs/1765444 |
17:06 |
|
mmorgan left #evergreen |
17:29 |
|
abowling1 joined #evergreen |
18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
20:26 |
|
jvwoolf joined #evergreen |
20:28 |
|
jvwoolf1 joined #evergreen |
21:01 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: updating 3.0.8 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1b8bbc3> |
21:01 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: updating 3.1.2 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aa6020b> |
21:15 |
|
jvwoolf1 left #evergreen |
22:29 |
|
abowling joined #evergreen |
06:31 |
pinesol_green |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live> |
06:31 |
pinesol_green |
News from qatests: Failed configure database <http://testing.evergreen-ils.org/~live> |
06:31 |
pinesol_green |
News from qatests: Failed Starting Evergreen <http://testing.evergreen-ils.org/~live> |
06:31 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
06:31 |
pinesol_green |
News from qatests: Failed Log Output: osrfsys.log - Expected 3 errors but encountered 4539. <http://testing.evergreen-ils.org/~live> |
06:40 |
csharp |
psql: could not connect to server: Connection refused |
06:40 |
csharp |
^^ those errors |
06:45 |
|
JBoyer joined #evergreen |
10:29 |
berick |
sandbergja++ # solo feedback fest |
10:43 |
|
kmlussier joined #evergreen |
10:54 |
miker |
csharp: there's still the issue of the template editor. I only addressed the live editor due to lack of tuits -- the request is, IIUC, to create a different code path for the template editor that uses staff permissions rather than selected copies to populate the dropdown. as for my fix in comment 2, I don't know if it's still needed or not, strictly, but it's a belt to wear with whatever suspenders have been added since the bug was reported |
11:03 |
csharp |
miker: ok - if it's useful to apply the patch you created way back when I'll test and sign off on it and sounds like the template editor issue should be a separate bug report |
11:11 |
miker |
csharp: I think it's probably useful to retest the patch. I honestly don't recall OTTOMH what else has changed in there over the last 5 months ... or if the "need to treat numbers as numbers" bug might still be lurking somewhere |
11:20 |
|
mmorgan1 joined #evergreen |
11:48 |
|
khuckins joined #evergreen |
15:59 |
abneiman |
terran++ |
16:15 |
|
mmorgan1 joined #evergreen |
16:17 |
|
agoben joined #evergreen |
16:23 |
jeffdavis |
we're seeing some web client admin interfaces (mostly acq related) fail to work in a load-balanced environment on 3.1 |
16:23 |
jeffdavis |
not sure yet if it's a configuration issue or what |
16:23 |
jeffdavis |
e.g. attempting to create a new acq funding source gives a 400 Bad Request error |
16:25 |
jeffdavis |
on POST to /osrf-http-translator |
16:26 |
jeffdavis |
I don't see the same issue in a non-load-balanced test environment |
16:26 |
miker |
jeffdavis: some things to check (which you probably have, but just in case): 1) every time? 2) are the memcache instance(s) shared? (they should be) 3) are services cross-registered amongst routers (and if not, are any down) |
16:26 |
miker |
and for (1) I mean is it intermittent |
16:29 |
jeffdavis |
seems to be consistent, at least for acq admin |
18:16 |
jeffdavis |
The SQL that I pasted above is how we fixed the issue. Run that before the 3.0.6-3.1.0 upgrade script. |
18:16 |
jeffdavis |
I thought there was a Launchpad bug for that but I can't find one. |
18:17 |
frank_g |
jeffdavis: thanks for your help |
18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
19:14 |
|
bdljohn joined #evergreen |
23:59 |
|
beanjammin joined #evergreen |
01:14 |
|
book` joined #evergreen |
05:35 |
|
beanjammin joined #evergreen |
06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:59 |
|
agoben joined #evergreen |
07:15 |
|
rjackson_isl joined #evergreen |
07:42 |
|
rlefaive joined #evergreen |
08:59 |
|
jvwoolf1 joined #evergreen |
09:00 |
|
bos20k joined #evergreen |
09:03 |
|
Dyrcona joined #evergreen |
09:10 |
csharp |
so I'm still having issues on my master test server (ubuntu 16.04), reinstalled today. When I pull up a bib record the Record Summary is not loading data. In the console (FF 60.0) I see "Possibly unhandled rejection: {}" |
09:11 |
csharp |
followed by "TypeError: cp.copy_alerts is not a function" and |
09:11 |
csharp |
"TypeError: rec.flat_display_entries is not a function" |
09:12 |
csharp |
as mentioned last week(?), I think this may be related to the version of Angular I'm using |
09:14 |
csharp |
Object { full: "1.6.9", major: 1, minor: 6, dot: 9, codeName: "fiery-basilisk" } |
09:14 |
csharp |
(output of "angular.version" in the dev console |
09:14 |
csharp |
) |
09:18 |
csharp |
same behavior on chrome 66 |
09:18 |
csharp |
same console errors |
09:19 |
csharp |
can anyone confirm or disprove? |
09:24 |
JBoyer |
csharp, I don't have a master install at the moment but I do have a server running angular 1.6.10 so I don't think it's the angular verison. |
09:29 |
csharp |
JBoyer: ok - thanks |
09:36 |
miker |
csharp: that sounds more like a mismatching fm_IDL.xml |
09:36 |
miker |
did you install over the top of an existing instance from source? |
09:40 |
|
bos20k joined #evergreen |
09:47 |
csharp |
miker: hmmm - I'll test that - yeah, it's been installed over and over |
09:53 |
csharp |
hmm 'diff /openils/conf/fm_IDL.xml Open-ILS/examples/fm_IDL.xml' shows no differences |
09:57 |
miker |
csharp: ah, but there's one exposed in the reporting area that's used by the JS |
09:58 |
miker |
fwiw, I tend to make that one a symlink to the one in /openils/conf/ to avoid them getting out of sync, unless you need i18n on the dev/test system |
09:59 |
|
Christineb joined #evergreen |
10:00 |
csharp |
oh... |
10:02 |
csharp |
miker++ # that fixed it |
10:29 |
Dyrcona |
So, the deleted field was apparently added "recently" and I have holds pointing to deleted parts where the parts were actually deleted from the database. |
10:30 |
Dyrcona |
Inconsistencies like that are a pain. |
10:41 |
|
jvwoolf joined #evergreen |
10:48 |
Dyrcona |
pingest-- # It's clobbering my test db server, and another script running on another database on the same server can't get any time to run. |
10:48 |
Dyrcona |
spoke too soon. looks like it is doing something now. :) |
10:58 |
idjit |
question about bug 1724348: what would be correct behavior if i set "holdings view" as the default view, open a record, switch to "marc view", go back to search results and open a new record? |
10:58 |
idjit |
should it load the holdings because that's my default or should it load marc view because that's the last tab i was looking at on a record? |
11:02 |
csharp |
are others seeing this? |
11:02 |
csharp |
even before attempting miker 's fix there, I'm not able to reproduce |
11:04 |
csharp |
since it's marked as a blocker, I'm hoping to either move it to invalid or at least remove the tag if others aren't seeing the problem |
11:04 |
* berick |
can test in a few minutes |
11:04 |
kmlussier |
csharp: I had hoped to look at that one, but I don't think I ever found that time to confirm or do any testing. |
11:07 |
csharp |
well, it's fairly simple to test on a concerto server - just create vols/copies for each branch in the system and see if they appear in the list - so far I'm not seeing the originally-reported problem |
11:07 |
csharp |
this was reported before we went live and was one of the bugs that led to our decision to not move cataloging to the web client yet |
11:35 |
kmlussier |
Dyrcona: Are those old holds where the parts were deleted before the patch from bug 937789 was added? |
11:35 |
pinesol_green |
Launchpad bug 937789 in Evergreen 2.8 "Deleting parts breaks hold interfaces" [Medium,Fix released] https://launchpad.net/bugs/937789 |
11:35 |
berick |
csharp: curious, are you still seeing one of the errors you mentioned earlier? i'm getting a "annot read property 'length' of undefined" on the hold maint. page. |
17:06 |
idjit |
haha, if we're real lucky it'll even work :-P |
17:07 |
Dyrcona |
:) |
17:09 |
|
mmorgan left #evergreen |
18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
02:27 |
|
rjackson_isl_ joined #evergreen |
06:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:02 |
|
agoben joined #evergreen |
07:18 |
|
rjackson_isl_ left #evergreen |
07:22 |
|
rlefaive joined #evergreen |
11:06 |
|
abowling joined #evergreen |
11:14 |
berick |
i'd appreciate an eyeball on this before posting to mail lists for reivew: https://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:angjs_to_ang_migration |
11:15 |
berick |
i'm way too close to it. |
11:16 |
gmcharlt |
berick: a couple things immediately jump out at me |
11:18 |
gmcharlt |
one, there should probably be something that (a) uses the <blink> tag (b) and the <marquee> tag, and (c) 72-point type to the effect that unit tests are /crucial/ for core services |
11:18 |
* berick |
dons geocities cap |
11:19 |
berick |
good point, thanks gmcharlt |
11:20 |
gmcharlt |
secondly, the project to angularize acquisitions falls in an uncomfortable place in the timeline you're proposing |
12:09 |
miker |
I don't much care where i18n happens, tbh. I'm concerned with that actual purpose of tt2 ... the i18n stuff we do there is really an add on of our own devising |
12:10 |
miker |
berick: I think that's not so true from some perspectives (TTFB more important that flexibility of configuration) |
12:18 |
|
khuckins joined #evergreen |
12:23 |
* berick |
updates doc to clarify proposal of bypassing TT2 and including unit tests for core services. |
12:25 |
berick |
i'll post to mail list later so we can resume discussion |
12:37 |
|
Christineb joined #evergreen |
13:01 |
miker |
thanks berick! |
13:10 |
miker |
re my comment about speed vs flexibility: in a "web app" world, while lazy loading is still a thing, most of the cost that tt2 imposes would still be paid on the initial app load, not on each interaction as it is right now in the tpac. the separation of display customization/restriction from page element rendering (in that, today, the "whole page" is rendered only after all logic completes, whereas that cost can be frontloaded in a web app so renderin |
15:05 |
_bott_ |
kmlussier: which indexes, specifically? It was a DB upgrade, so there were existing changes in legacy tables. |
15:11 |
kmlussier |
_bott_: IIRC, it's important to ensure that your search fields are also enabled as display fields. You're right, that change should have been made to legacy tables in the upgrade script. |
15:12 |
kmlussier |
The display fields also need to be used in the tt2 files, but, if you're using out-of-the box templates, that should already be there. Also, the reingest is required. |
15:19 |
_bott_ |
kmlussier: yes, I caught the display_field updates, those are good to go. The logs show the cstore calls to search.highlight_display_fields, I'm trying to parse one of those out to test it directly, but it looks to be returning successfully. |
15:20 |
kmlussier |
_bott_: OK, that's all I've got. |
15:26 |
JBoyer |
_bott_, Nothing else is coming to me either, I just realized I kind of wandered off there. The only trouble I had with highlighting is deciding what color I'm going to change the default to for the production upgrade. |
15:26 |
_bott_ |
DOH! metabib.display_entry table is empty! |
16:17 |
|
khuckins joined #evergreen |
17:04 |
Bmagic |
jeff++ # Forensic science |
17:09 |
|
mmorgan left #evergreen |
17:14 |
pinesol_green |
[evergreen|Remington Steed] Docs: Update Long-overdue docs for web client - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e9b08bc> |
17:54 |
|
Christineb joined #evergreen |
18:32 |
|
beanjammin joined #evergreen |
18:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
23:05 |
|
jeff_ joined #evergreen |
23:12 |
|
jeff__ joined #evergreen |
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:13 |
berick |
I'll bring the moonshine jug |
12:16 |
|
khuckins joined #evergreen |
12:18 |
jeff |
gsams: need more info. reducing workflow/UI steps? speed of "renew all"? speed of individual renewal of an item where there may be item or record-specific circumstances leading to a delay in renewing? something else? |
12:19 |
gsams |
jeff: Apologies, meant to go into more detail. At the moment just speed of "renew all" seems to be the biggest thing |
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> |