05:42 |
|
jonadab joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
12:00 |
|
miker joined #evergreen |
12:05 |
|
gmcharlt joined #evergreen |
12:11 |
|
Dyrcona joined #evergreen |
13:59 |
Dyrcona |
Well, I still manged to mess it up. |
14:17 |
csharp_ |
Dyrcona: thanks for the info! |
14:22 |
Dyrcona |
csharp_: You're welcome. |
14:24 |
Dyrcona |
I believe I have something that works with savepoint. After 1 more test run with 1 item at a time, I'll take a break. After that, I'll write a program to test a mix of items that should fail and succeed. If that works, I'll make the necessary changes to the staff client, and then update the release notes and squash the branch again. |
14:26 |
Dyrcona |
Yeah, tests still work. Maybe I'll add the test of multiple copies to the live test file rather than write a whole new program.... |
16:07 |
Dyrcona |
So, I'm returning an array ref in the back end call. Are there examples of using such a thing in AngularJS? |
16:13 |
Dyrcona |
I think I can just use it as an array. We'll see. |
16:32 |
Dyrcona |
Anyone know if I can set values in a toast? I though I could just assign a field on $scope. |
16:47 |
Dyrcona |
Well, now my toast is empty.... |
16:54 |
Dyrcona |
I'll let this go for now and I might look into it later. I've already gone over time. |
17:53 |
|
mantis joined #evergreen |
18:00 |
pinesol |
News from qatests: Failed Installing AngularJS web client <http://testing.evergreen-ils.org/~live//archive/2022-01/2022-01-08_16:00:02/test.28.html> |
18:04 |
|
jvwoolf1 joined #evergreen |
18:32 |
JBoyer |
Oops, accidentally posted this on the feeds channel. So, if you are annoyed like I am about that stupid mess in the mile-long log above it appears to be a forgotten line that was supposed to be removed from the colors package: https://github.com/Marak/colors.js/blob/master/lib/index.js |
18:32 |
JBoyer |
I wonder how many more dependencies he pulled in to use .zalgo on that. 🙄 |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:42 |
|
Christineb joined #evergreen |
07:31 |
|
rjackson_isl_hom joined #evergreen |
08:20 |
|
rjackson_isl_hom joined #evergreen |
14:31 |
alynn26 |
me |
14:32 |
dluch |
dbs: you want to lead off? |
14:32 |
dluch |
(I switched the order of new business items, btw) |
14:33 |
dbs |
So first up: correction to my most recent post. |
14:33 |
dbs |
You can download the full set of documentation from every commit / branch in GitLab Pages |
14:33 |
dbs |
(nothing needs to be figured out, other than my overtired brain) |
14:34 |
dbs |
Second: in 3.0 best practice is still to keep a separate git repo for the base Antora build stuff. So I would revert that |
14:36 |
dbs |
Third: working in GitLab or GitHub these days feels like lightyears ahead of CLI-based git workflows, given integrated issue tracking, project planning, Web IDE for drive-by contributions, merge request reviewing, etc |
14:36 |
|
bott_grpl joined #evergreen |
14:36 |
dbs |
but that one is way outside of the scope of "making it easier to build and test docs" and a much bigger discussion |
14:36 |
alynn26 |
I actually like working in GitHub better than the CLI. :) |
14:37 |
Bmagic |
do we need to migrate the Evergreen repository to a gitlab server in order to get this? We've talked about it as a replacement for Launchpad in a different dev discussion a couple of years ago (probably more because you have to skip the pandemic year(s)) |
14:37 |
abneiman |
I definitely prefer a GUI also, but I've gotten accustomed to operating within the CLI to the point where I'd need a github refresher to do the same work there |
14:38 |
alynn26 |
A better way to build and test docs that is more intuitive is better. |
14:39 |
dbs |
Bmagic: hmm - I'm mirroring the git repo on GitLab (have been since it was on gitorious like ten years ago). I don't think a mirrored branch triggers a GitLab CI/CD thing but I can check |
14:40 |
abneiman |
alynn26: hard agree about streamlining build/test of docs - it's a major roadblock right now |
14:40 |
dbs |
it might be possible to trigger a rebuild using something like a particular branch name, like docs-build or something hacky... make that a to-do for me |
14:41 |
dluch |
Sure |
14:41 |
Dyrcona |
FWIW, we run gitlab at CW MARS mainly just to try it out. We don't do any fancy CI/CD stuff though. |
14:41 |
Bmagic |
Having our about-to-be submitted docs reviewed and integrated into the Evergreen Docs look and feel would be super tasty. The routine would be to submit your test changes to a certain pre-defined Git branch, and poof, a minute later, it's rendered on a page somewhere |
14:41 |
dbs |
alynn26 abneiman: even the small win of "can't merge this because you introduced an error" with a clear error message in the branch discussion is so nice |
14:42 |
dluch |
#action dbs will see if it's possible to trigger a rebuild using something like a particular branch name, like docs-build or something hacky |
14:42 |
alynn26 |
Clear error messages would be a win for me. |
15:51 |
|
_collum joined #evergreen |
15:59 |
|
mantis joined #evergreen |
16:14 |
|
jihpringle joined #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:42 |
|
collum joined #evergreen |
08:07 |
|
rjackson_isl_hom joined #evergreen |
08:15 |
|
mantis joined #evergreen |
11:46 |
miker |
and they're both restricted to 1 file, so, easy peasy |
11:46 |
csharp_ |
yep |
12:23 |
mmorgan |
Has anyone gathered some experience with 3.7+ in a production database with saving/loading bib records? We're trying to get an idea of the effect of the symspell dictionaries for did you mean. |
12:26 |
csharp_ |
mmorgan: we're going to 3.8 next month - running it on a training/testing server that is production-ish, datawise |
12:26 |
csharp_ |
what should we be looking out for? |
12:26 |
jeff |
We're not relying on "did you mean" and did not populate the related tables as part of our upgrade. I've noticed a deadlock or two which have made me want to look into disabling the relevant triggers until I have time to look into it more. |
12:28 |
jihpringle |
mmorgan: we're running 3.7.0 and do not have "did you mean" turned on. In testing with it on we couldn't save any MARC records |
12:29 |
jihpringle |
we haven't tested with any of the post 3.7.0 "did you mean" fixes yet |
12:29 |
mmorgan |
csharp_: Our big concern is loading records with 856 links. We do a lot of that, but general saving and loading of bib records via vandelay is our concern, too. |
12:31 |
mmorgan |
We've just begun testing with production data and so far are seeing the records with 856 links taking MUCH longer, also getting general.unknown error for some records that have failed to load. |
12:31 |
mmorgan |
jeff: Not sure what you mean by a 'deadlock' ? |
12:32 |
mmorgan |
jihpringle: We've loaded some of the post 3.7.0 fixes. |
12:32 |
berick |
jeff: if you decide to disable, mind sharing what all you disable? |
12:33 |
mmorgan |
We're very early in testing, and were just wondering if others were ahead of us and had experiences regarding saving/loading records. |
12:38 |
mmorgan |
jihpringle: Have you done anything other than turning off "did you mean"? My thinking is that even with it off, the sysmpell dictionaries in the database would still be updated without disabling triggers like jeff mentions. |
12:38 |
csharp_ |
mmorgan: a deadlock is a postgresql level problem where two processes are waiting on each other to release the lock on a paritcular tuple ("row") |
12:39 |
mmorgan |
csharp_: Ah. Ok, thanks. I think I've seen log entries complaining about tuples. |
12:39 |
jeff |
mmorgan: the postgresql logs will log a deadlock when the database detects that process X and process Y (and maybe process Z) are all waiting on things that each other are waiting on. It's one of the reasons that pingest doesn't do certain bib-related ingest things in parallel. |
12:45 |
pinesol |
csharp_: The operation succeeded. Quote #219 added. |
12:46 |
csharp_ |
when it comes down to it, aren't we all just "waiting for more data from parent"? |
12:48 |
* csharp_ |
is referring to the server error mentioned yesterday http://irc.evergreen-ils.org/evergreen/2021-12-14#i_497049 |
13:00 |
mmorgan |
testing a file of 1000 records with 856 links on our 3.7 test system is not looking good. 6% progress after an hour, and most failed. |
13:03 |
JBoyer |
There are a couple dym-related patches that you may not have depending on your 3.7.X version. Since they're all just function updates they can be applied anytime and absolutely should be if you don't have them. |
13:03 |
JBoyer |
Sadly, I don't actually have a list handy to refer to... |
13:05 |
jeff |
...and Launchpad search returns 101 open tickets on a search for "did you mean"... :-P |
16:49 |
JBoyer |
I quite enjoyed this log4j take: https://twitter.com/leanrum/status/1470954707120181253 |
17:01 |
|
mmorgan left #evergreen |
18:00 |
|
jihpringle joined #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
19:01 |
|
eglogbot joined #evergreen |
19:01 |
|
Topic for #evergreen is now Welcome to #evergreen (https://evergreen-ils.org). This channel is publicly logged. |
19:32 |
|
jihpringle joined #evergreen |
04:41 |
|
denials joined #evergreen |
04:41 |
|
tsadok joined #evergreen |
04:42 |
|
jweston_ joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:18 |
|
rjackson_isl_hom joined #evergreen |
08:25 |
|
mantis joined #evergreen |
09:49 |
|
rfrasur joined #evergreen |
10:14 |
berick |
could play an error sound too |
10:14 |
jeff |
hah, I was just thinking of an amusing error sound. |
10:15 |
berick |
*sad trombone* |
10:23 |
jeff |
okay, yes. looks like I can happily call egAlertDialog within services/net.js for a method error. I might leave that in place on my test instance for a while and see what it surfaces. |
10:24 |
jeff |
in the case of missing pieces where I have a method error and added a second function to the promise to surface that error on that specific action, I end up with two egAlertDialogs. :-) |
10:32 |
jeff |
having recently upgraded, I find myself wanting a test instance with our previous version of Evergreen... oops. :-) |
10:40 |
|
bshum joined #evergreen |
10:42 |
jeff |
bah: |
10:42 |
jeff |
> We detected an application built with production configuration. Angular DevTools only supports development builds. |
10:59 |
|
mmorgan joined #evergreen |
11:21 |
|
abowling joined #evergreen |
11:47 |
|
Keith-isl joined #evergreen |
15:07 |
Dyrcona |
Mechanical wit, but then it runs out and you have to buy more. Plus it leaves bits all around. |
15:07 |
JBoyer |
Ok, people should feel free to #info up as they continue to join. |
15:07 |
JBoyer |
#topic Action Items from Last Meeting |
15:07 |
JBoyer |
#info JBoyer will test out the branch in lp 1947595 |
15:08 |
pinesol |
JBoyer: Error: Could not gather data from Launchpad for bug #1947595 (https://launchpad.net/bugs/1947595). The error has been logged |
15:08 |
JBoyer |
I'm as surprised as you all may be, but that did happen and the branch was even signed off on because it does the thing. Dyrcona ++ |
15:08 |
Dyrcona |
JBoyer++ |
15:18 |
pinesol |
Launchpad bug 1953044 in OpenSRF "Perl services can crash with a "Use of freed value in iteration" error" [Medium,Confirmed] https://launchpad.net/bugs/1953044 |
15:18 |
gmcharlt |
the latter two are currently in production at Equinox |
15:19 |
gmcharlt |
the first one is a little more prospective |
15:19 |
Dyrcona |
I'll see if I can make some time to test a couple of those. |
15:19 |
csharp_ |
these are the "think of the children!" branches you mentioned before |
15:19 |
gmcharlt |
yup |
15:21 |
JBoyer |
Sounds like a plan, hopefully all 3 of those can get some testing and make it in soon. Any other OpenSRF discussion? |
15:22 |
jeffdavis |
(testing some of those is on my todo list fwiw) |
15:22 |
JBoyer |
jeffdavis++ (and Dyrcona ++ and gmcharlt ++ ) |
15:22 |
JBoyer |
If not, and given the placholders holding places we can skip down to |
15:23 |
JBoyer |
#topic Launchpad Status |
15:27 |
csharp_ |
do we have a sense of how well Edge Just Works™? |
15:27 |
csharp_ |
and to be clear, we're talking about Edge that's based on Chrome, yes? |
15:27 |
Dyrcona |
I believe so. |
15:27 |
JBoyer |
So, with the fact that it's literally Chromium + MS sync instead of Google Sync it works pretty well. shulabear took the client for a test drive and found no potholes. |
15:27 |
alynn26 |
I know of several people who use it. it works great for them. |
15:28 |
csharp_ |
maybe support it with a huge YMMV warning? |
15:28 |
JBoyer |
Yeah, Not-Chromium Edge is no bueno, even for MS. |
15:28 |
shulabear |
I've encountered no issues with it in testing, as long as it's the Chromium version. |
15:28 |
csharp_ |
that's the way we support MacOS here in PINES |
15:28 |
csharp_ |
"feel free, but it's on you" |
15:29 |
mmorgan |
What does "supporting Edge" entail? |
15:31 |
csharp_ |
I guess Hatch should be in the mix of what "support" means too? |
15:32 |
JBoyer |
csharp_, it works fine as-is, just isn't yet on the Edge Extension thing. (though you can install it via the chrome web store I believe) |
15:32 |
csharp_ |
I don't have a strong feeling/preference either way, which I guess is effectively "yes" |
15:34 |
JBoyer |
It's also possible to test the Angular client with the linux version by setting CHROMIUM_BIN to the right path. (I don't actually recommend using my branch to add the edge npm launcher because there's no good way to handle missing browsers. :/ ) |
15:35 |
JBoyer |
I'm for it personally because it's extremely low effort and it's possible that local IT may standardize on it anyway so staff may as well know we'll make sure it works. |
15:36 |
alynn26 |
+1 |
15:36 |
gmcharlt |
+1 |
15:39 |
JBoyer |
oops. Let the minutes show that's 11, 0, 1, not that it was a close call. :) |
15:39 |
JBoyer |
#topic Support for Newer PostgreSQL Versions |
15:39 |
JBoyer |
Dyrcona, how's things? |
15:40 |
Dyrcona |
Well, there are branches, one of which has been tested and signed off. |
15:40 |
miker |
soon to be committed :) |
15:40 |
Dyrcona |
mker looked at the other and had some questions about the XML changes. I'll go back an make them more consistent, using local-name() instead of namespaces. |
15:41 |
Dyrcona |
I'd like to get this in before the next Evergreen release. (3.9?) |
15:41 |
miker |
seems likely, imo |
15:42 |
Dyrcona |
The tests all pass, but I think there are places, like located URIs where performance suffers on newer Pg versions. |
15:42 |
miker |
I think I owe eyes on an old branch for that, in particular |
15:43 |
Dyrcona |
my three big questions are: 1. I'd like the Stretch removal branch to go in first, so that we don't have to mess with stretch prerequisites. |
15:43 |
JBoyer |
That shouldn't be an issue for 3.9 |
15:46 |
miker |
that complicates or delays dealing with some performance issues in 11+ re CTEs, but that's just timing I guess |
15:47 |
Dyrcona |
Well, we could remove the non-versioned db prerequisite and word the read me to recommend 10 in production environments. |
15:48 |
miker |
And by that I mean CTEs may need 11+ only syntax changes to avoid speed regressions |
15:48 |
JBoyer |
True, I kind of meant "if we can knock them out" when I said "other than these problems" :) but since we've had 9.6 and 10 available for some time we should probably have 10 and 14 available for those who want to test |
15:50 |
gmcharlt |
yeah, "it works" is sufficient for offering the option to install with newer versions, but I think the production recommendations need to avoid known performance regressions |
15:50 |
JBoyer |
I can +1 that. |
15:51 |
mmorgan |
+1 |
15:57 |
shulabear |
Dyrcona++ |
15:57 |
JBoyer |
#topic Migrating to Angular 12 sooner than later? |
15:57 |
JBoyer |
berick, how does it look? |
15:58 |
berick |
oh sorry |
15:58 |
berick |
minus a few broken unit tests, my initial Ang 12 upgrade process worked as expected |
15:59 |
JBoyer |
The angular update site makes it look like we can make that jump without any real code changes, which is good. |
15:59 |
berick |
if we want to update before EG 3.9 I'd prefer sooner than later |
15:59 |
sandbergja |
berick: does the linter still work? I remember something about some linting changes |
15:59 |
berick |
yeah, it was not such a big doeal |
15:59 |
berick |
sandbergja: don't recall if I tested. I can, though, when I rebase |
15:59 |
sandbergja |
berick++ |
15:59 |
sandbergja |
thanks |
16:00 |
berick |
ideally we could pick a merge date and me and whoever else can help will get it merged |
16:38 |
miker |
jboyer++ |
16:38 |
|
mmorgan left #evergreen |
16:39 |
sandbergja |
claiming 1309 |
16:42 |
pinesol |
[evergreen|malexander] lp-1942645 term name uniqueness - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a11ce47> |
16:42 |
pinesol |
[evergreen|Jane Sandberg] LP 1942645: stamp upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e79df5d> |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
00:57 |
|
abowling1 joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:47 |
|
rjackson_isl_hom joined #evergreen |
08:36 |
|
mmorgan joined #evergreen |
08:52 |
|
rfrasur joined #evergreen |
12:02 |
mmorgan |
berick++ # bug 1954301 |
12:02 |
pinesol |
Launchpad bug 1954301 in Evergreen "Hatch Browser Extension Sometimes Fails to Respond" [High,Confirmed] https://launchpad.net/bugs/1954301 - Assigned to Bill Erickson (berick) |
12:11 |
mmorgan |
berick: Assuming no issues are found with your patch, how does the fix proceed? Does it just come down to an update to the Chrome extension? Just wondering if we should start loading the unpacked extension on affected workstations. |
12:17 |
berick |
mmorgan: once it's merged, I'll post it to the Chrome store. after that, the extension should automatically update in the browser. |
12:18 |
berick |
csharp_: wondering if you have any cycles to test the extension changes in Firefox... https://launchpad.net/bugs/1954301 |
12:18 |
pinesol |
berick: Error: Could not gather data from Launchpad for bug #1954301 (https://launchpad.net/bugs/1954301). The error has been logged |
12:18 |
berick |
i'll try to do the same today |
12:18 |
mmorgan |
berick: ok, thanks! |
12:20 |
mmorgan |
jeff++ |
12:20 |
* jeff |
waves |
12:34 |
jeff |
oh hey, i should probably remove the .firefox from the this filename if I expect it to work: org.evergreen_ils.hatch.firefox.json |
12:42 |
berick |
my initial FF tests show the extension changes working as expected |
12:42 |
jeff |
hah, beat me to it. |
12:51 |
jeff |
tests well here on 96.0b3 for macOS |
12:52 |
jeff |
I can sign off and commit if you want to do the chrome/firefox extension bits on a Friday... |
12:57 |
JBoyer |
Does anyone need to print receipts on a weekend? |
12:57 |
JBoyer |
;D |
13:01 |
berick |
jeff: i'll be squashing the commit post-sign if that's OK w/ you (to remove some cruft, add some more code comments) |
13:03 |
jeff |
feel free either way. i haven't pushed a signoff but i could do one after if you like. |
13:04 |
berick |
ok, thanks |
13:04 |
berick |
lemme push a cleanup.. |
13:07 |
jeff |
We did encounter this on a few workstations this week after our upgrade, but when I went looking for workstations to test on, there appeared to be none that still had the issue... so, I'm confirming that it doesn't break anything that I can see, the fix looks logical, and I'm relying on mmorgan and others to confirm that it is an effective fix. :-) |
13:08 |
* mmorgan |
has been working in the client with the new extension and has seen no issues. |
13:09 |
mmorgan |
But I do wonder about deploying on a Friday... |
13:10 |
berick |
jeff: pushed user/berick/lp1954301-ext-tab-message-order-v2 w/ a single cleaned up commit. |
15:08 |
|
jvwoolf joined #evergreen |
16:22 |
|
jvwoolf left #evergreen |
17:10 |
|
mmorgan left #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
04:08 |
|
JBoyer joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:33 |
|
rjackson_isl_hom joined #evergreen |
07:48 |
|
collum joined #evergreen |
08:19 |
|
rfrasur joined #evergreen |
10:35 |
pinesol |
Dyrcona: Excel/xlsx WILL PERISH UNDER MAXIMUM DELETION! DELETE. DELETE. DELETE! |
10:36 |
Dyrcona |
Looking at the log more carefully, I see this: Dec 9 10:34:05 jasontest open-ils.cstore: [INFO:6887:osrf_application.c:1075:] CALL: open-ils.cstore open-ils.cstore.direct.asset.copy.search {"barcode":"3.0453000494612E13","deleted":"f"},{"flesh_fields":{"acp":["circulations"]},"flesh":1} |
10:37 |
jeff |
aha! |
10:37 |
Dyrcona |
The barcode is a "number" according to that output. I guess only the barcodes that begin with the letter A are working. Now, why this happens on the test vm and not in production... Hm. I edited the sheet in LibreOffice this morning. Maybe that "fixed" it? |
10:38 |
jeff |
(now some fun is to be had with determining if the text->number type confusion happened at log time or before.) |
10:39 |
Dyrcona |
jeff: It's before. Excel does that with barcodes. I think the spreadsheet I used in production was editing in LibreOffice. I'll copy it to the test vm again and see what happens. |
10:39 |
jeff |
oh, if you're using Spreadsheet::Read and the input barcode file is different between test and production, I suspect the input file is your issue now. |
10:40 |
* jeff |
nods |
10:42 |
Dyrcona |
yeahp. It's chugging away, now. |
10:42 |
Dyrcona |
GIGO |
10:44 |
Dyrcona |
So, they want the already deleted copies checked in, so I should go back to the cstore session or editor, remove the deleted=>'f', etc., etc., and so on and so forth. |
16:22 |
bott_grpl |
But exactly what I was looking for! |
16:22 |
bott_grpl |
berick++ jeffdavis++ |
17:31 |
|
jvwoolf left #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:45 |
pinesol |
[evergreen|Jason Stephenson] Lp 1862652: pingest.pl reingest record attributes fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5ac76ef> |
23:03 |
|
alynn26_away joined #evergreen |
04:15 |
|
alynn26_away joined #evergreen |
04:15 |
|
alynn26_away joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:23 |
|
rjackson_isl_hom joined #evergreen |
07:26 |
|
rjackson_isl_hom joined #evergreen |
08:38 |
|
mmorgan joined #evergreen |
11:44 |
mmorgan |
Huge disruption at circ desks when that was introduced. |
11:47 |
Dyrcona |
miker: Pg 11 and Pg 12 release notes, plus previous IRC discussion. Guess I typoed the commit header. I'll fix it if I get around to it. |
11:48 |
Dyrcona |
Failure mode is database functions don't work. |
11:48 |
Dyrcona |
Perl and Pgtap test fail. |
11:48 |
miker |
heh, well, I figured /that/ much :) |
11:49 |
Dyrcona |
Well, the commits fix the tests, so there you go. |
11:49 |
Dyrcona |
I figured this would wait until after next week's dev meeting anyway. |
11:49 |
miker |
I was looking for an LP bug as I thought that might have error messages, is all. there's a mix of namespace addition and local-name() and I'm trying to understand the details |
11:50 |
miker |
I mean, sure, it can. I just happened to be in some similar areas |
12:15 |
|
jonadab joined #evergreen |
12:18 |
jeff |
We also ditched the sms_check constraint on action.request, as we don't need or care about sms_carrier. |
12:23 |
jeff |
and needed to change some bits on the place hold screen, because sms-related settings that weren't being shown were preventing the form from being submitted. :-) |
12:36 |
Dyrcona |
miker: I got the obvious things that have tests. More eyes are welcome. |
12:37 |
* miker |
fires up sed |
12:52 |
mmorgan |
jeff: bug 1933381 |
12:52 |
pinesol |
Launchpad bug 1933381 in Evergreen 3.6 "Angular: place hold fails with a generic error when Notify by SMS is selected without a carrier" [Low,Fix released] https://launchpad.net/bugs/1933381 |
16:30 |
|
jamin joined #evergreen |
16:35 |
jamin |
Are there any good docs for making proper use of user activity types? As in creating a new one? (Which I've done, and have III Patron API working for one org, but... just making up values to stuff in the fields doesn't seem right, and am not surprised to see nothing end up in the user activity table.) |
16:36 |
|
jvwoolf left #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:30 |
|
rjackson_isl_hom joined #evergreen |
07:47 |
|
collum joined #evergreen |
08:36 |
|
mantis joined #evergreen |
15:17 |
mmorgan |
It does seem to have something to do with Hatch. My Chrome has the Hatch Chrome plugin installed, but Hatch is not enabled in Evergreen. |
15:18 |
mmorgan |
This doc shows screenshots of what the screens look like, and the console: https://docs.google.com/document/d/1d5dC1LhgZgPbXeFDWcmbCjRCotFl3fZSC5-GlJVyBic/edit?usp=sharing |
15:18 |
jeff |
do you have steps that you can reliably reproduce? |
15:18 |
mmorgan |
When we see the whilte screen, this is the last line in the console: |
15:18 |
mmorgan |
sending to Hatch: {"key":"eg.workstation.all","action":"get","msgid":1} |
15:20 |
mmorgan |
I didn't want to destroy my test environment, but I *think* this is happening only on angularjs screens. |
15:20 |
mmorgan |
Any thoughts? |
15:20 |
jeff |
are there any clues in hatch.log? |
15:20 |
alynn26 |
That is what we are seeing. We are also seeing it with some of the Angular screens. but not much. |
15:22 |
mmorgan |
dumb question time: Where will I find hatch.log? |
15:23 |
jeff |
you can usually enter %userprofile% in Start -> Run |
15:23 |
jeff |
unless you've changed the location in logging.properties |
15:24 |
jeff |
or unless your file permissions on logging.properties prevent it from being read, in which case I forget what the default is. might be "no log" |
15:26 |
berick |
cd 'C:\Program Files(x86)\Hatch' ; \.hatch.bat test |
15:27 |
berick |
can also be useful |
15:27 |
mmorgan |
Hmm. Not seeing a .evergreen directory for my userprofile |
15:28 |
berick |
correction: .\hatch.bat |
15:29 |
mmorgan |
csharp_: I see the background page for the Hatch extension, but don't see anything that looks like an error there. |
15:43 |
mmorgan |
jeff: I think that is true, but will confirm. |
15:43 |
jeff |
what version of Evergreen and Hatch are you running? |
15:44 |
jeff |
guessing Hatch 0.3.2, but not wanting to assume. |
15:45 |
mmorgan |
jeff: Confirmed: no corresponding "Hatch responded to message ID 1" in the browser console. |
15:47 |
mmorgan |
I refresh, the screen loads, and I see "Hatch responded to message ID 1" in the browser console. |
15:48 |
mmorgan |
jeff: Hatch 0.3.2 |
15:50 |
mmorgan |
I logged into the client on 3 different servers this morning, production, test, and dev. I am no longer seeing the problem in production, but am still seeing it in test and dev. |
15:51 |
mmorgan |
Neglected to say that this was all in the same Chrome window, different tabs, and all showed the problem. |
15:53 |
berick |
i wonder if it's getting hung up on something else.. |
15:53 |
berick |
mmorgan: go to chrome://inspect/#workers and click on 'inspect' for https://HOSTNAME/js/ui/default/staff/offline-db-worker.js |
15:54 |
berick |
see if anything in there complains when the page fails to load |
16:00 |
mmorgan |
3.6.4, 3.7.2 and another flavor of 3.6, I believe. |
16:01 |
mmorgan |
berick: the inspect page seems to refresh itself. The listed servers blink on and off depending on whether the screens load or not. |
16:01 |
Dyrcona |
If I apply that patch for the symspell stuff on a system where it has already been ingested once before, do I have to do it again? |
16:02 |
berick |
mmorgan: hm, it's inconsistent for me. just tested again and had to refresh. *shrug* |
16:03 |
jeff |
i wonder what you'd see if you go to chrome://extensions, enable Developer mode, and then select the "background page" link for Hatch Native Messenger. |
16:04 |
mmorgan |
berick: tried refreshing several times when on an incomplete screen. The server doesn't show under Shared workers. |
16:05 |
jeff |
I get the behavior you've described 100% of the time when I have the hatch browser extension installed but no native messaging host (no Java bits). 100% as in it's not intermittent / fixed with a reload, it just fails every time. |
17:00 |
mmorgan |
alynn26++ |
17:00 |
mmorgan |
JBoyer++ |
17:05 |
|
mmorgan left #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
03:47 |
|
eglogbot joined #evergreen |
03:47 |
|
Topic for #evergreen is now Welcome to #evergreen (https://evergreen-ils.org). This channel is publicly logged. |
04:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
05:42 |
|
rjackson_isl_hom joined #evergreen |
07:13 |
|
rjackson_isl_hom joined #evergreen |
07:23 |
|
collum joined #evergreen |
11:14 |
pinesol |
Launchpad bug 1904036 in Evergreen "Port patron interfaces to Angular (search, checkout, etc.)" [Wishlist,New] https://launchpad.net/bugs/1904036 |
11:34 |
|
rjackson_isl_hom joined #evergreen |
12:07 |
|
jihpringle joined #evergreen |
12:07 |
jeff |
well that's new. a 3.7 test install does not have my usernameworkstation nor the log out / about menu. |
12:07 |
jeff |
a different 3.7 test install has it, and a 3.8 install has it. |
12:08 |
jeff |
(tested in ingognito also) |
12:12 |
jihpringle |
jeff: I ran into that using the 3.8 community server - I had to clear my cache and cookies and close Chrome to get it back |
12:12 |
jihpringle |
I haven't been able to reproduce yet |
12:18 |
jeff |
interesting. I would have thought that an incognito window would have addressed all that. so far, I can reproduce it all the time. :-) |
13:26 |
jvwoolf |
mmorgan: Yeah, that seems likely |
13:26 |
jvwoolf |
mmorgan++ |
13:27 |
* mmorgan |
needs to run away for a bit, but it would be great to add heat to that! |
14:10 |
jeff |
Hrm. "place hold for this staff account" seems to be working for me in a 3.7.2 test system, but not when I try to place the hold for my 'normal' patron. Place Hold(s) button isn't enabled. |
14:10 |
* jeff |
looks |
14:32 |
jeff |
ah, users with sms hold notification enabled but no carrier/etc. drat. we'll have to figure a solution there. |
14:33 |
jeff |
we might just start using a different opt-in user setting, but that might change too many other things. |
14:44 |
|
rjackson_isl_hom joined #evergreen |
17:04 |
|
mmorgan left #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:17 |
|
jihpringle joined #evergreen |