| 03:46 |
|
rlefaive joined #evergreen |
| 03:59 |
|
rlefaive joined #evergreen |
| 04:22 |
|
rlefaive joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:38 |
|
rlefaive joined #evergreen |
| 06:53 |
|
agoben joined #evergreen |
| 07:15 |
|
Dyrcona joined #evergreen |
| 10:24 |
Dyrcona |
Did someone mention in here recently that ou settings that are ints but stored as strings, ie. with "" around them, are not working in the web staff client? |
| 10:24 |
Dyrcona |
I seem to recall someone mentioning that. |
| 10:30 |
Dyrcona |
Oh... dataype = link appears to be treated as text when being set. |
| 10:30 |
Dyrcona |
Anyway, I'll test my numbers vs. strings hypothesis first. |
| 10:32 |
Dyrcona |
Well, whether that's an issue or not (number vs. strings), changing the ou settings values didn't solve my problem.... to the cod! |
| 10:32 |
Dyrcona |
or the code, rather. |
| 10:32 |
Dyrcona |
Not sure cod would be so helpful. |
| 11:21 |
|
mmorgan joined #evergreen |
| 11:21 |
Dyrcona |
debugger++ |
| 11:21 |
* berick |
makes a patch |
| 11:21 |
* Dyrcona |
will test. |
| 11:22 |
Dyrcona |
In fact, it looks like the only things in my egCore.env.aous array are the things that appear in local storage. |
| 11:22 |
Dyrcona |
Should there be a handler to look them up if they're not there? |
| 11:25 |
berick |
yeah |
| 17:07 |
|
mmorgan left #evergreen |
| 17:09 |
|
yboston joined #evergreen |
| 18:29 |
|
rlefaive joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:32 |
idjit |
cat! https://i.imgur.com/J8rMcvM.gifv |
| 18:32 |
|
rlefaive joined #evergreen |
| 18:32 |
idjit |
more on topic: i just added a branch for bugs 1669856 and 1776557. i hope it's ok that i put the two together into one branch; they're very closely related. please let me know if they need to be split up. |
| 02:36 |
|
beanjammin joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:46 |
|
JBoyer joined #evergreen |
| 07:03 |
|
agoben joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 12:10 |
Phillip |
JBoyer, I thought this was the case. |
| 12:18 |
|
beanjammin joined #evergreen |
| 12:27 |
|
yboston joined #evergreen |
| 12:29 |
Phillip |
When printing a holds pull list with Chrome/hatch, it prints receipt font size on a regular printer. Under test print, choosing Print does the same. |
| 12:29 |
Phillip |
Under test print, choosing Print with dialog prints fine. When I turn off hatch it prints fine. I've uninstalled Chrome/hatch without resolving the issue |
| 12:30 |
Phillip |
I used a different profile on the same computer and I'm having the same issue |
| 12:41 |
|
NFPL joined #evergreen |
| 12:43 |
JBoyer |
Phillip, after enabling Hatch there are additional steps you need to take: In the Administration menu select Workstation, then click Printer Settings. Here you would set up the various contexts and what printers are used for which context. |
| 12:45 |
JBoyer |
You may have done that part already but for reasons lost to time the default context for receipts is unset, so they use the default context unless you manually change that. To check that, go to the Print Templates page of the Workstation Administration, choose the receipt type you want to test, then make sure that the Context is Receipt. |
| 12:45 |
JBoyer |
Try again and see if that helps. |
| 13:01 |
|
NFPL joined #evergreen |
| 13:03 |
|
khuckins joined #evergreen |
| 13:18 |
NFPL |
Miker: Thanks! |
| 14:02 |
Phillip |
JBoyer: When I set these up, I go ahead and choose the printer for Default, Receipt, Label, Mail, and Offline and click Save for each one. I'll use Mail for the letter size printer. |
| 14:05 |
Phillip |
As an experiment, I changed Default, Receipt, Label, Mail and Offline to print to the Kyocera and clicked Apply Changes for each one. On the screen it's indicating for example letter size paper. |
| 14:06 |
Phillip |
But when I test printing, clicking Print, it's printing receipt printer font size on the Kyocera. It's as if the settings aren't being applied. If I click Print with dialog, it prints ok. |
| 14:11 |
|
yboston joined #evergreen |
| 14:48 |
|
rlefaive joined #evergreen |
| 14:48 |
dbs |
miker: it's probably not good security hygiene that people are replying to the governance mailing list with their scanned signatures attached (the curse of hitting "reply" to a mailing list)? |
| 17:53 |
krvmga |
Thanks! |
| 17:53 |
jihpringle |
np :) |
| 18:27 |
|
beanjammin joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:58 |
|
bdljohn joined #evergreen |
| 19:40 |
|
beanjammin joined #evergreen |
| 23:34 |
|
jeff_ joined #evergreen |
| 01:22 |
|
beanjammin joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:06 |
|
Dyrcona joined #evergreen |
| 08:40 |
|
idjit joined #evergreen |
| 08:46 |
Dyrcona |
Interesting change in Firefox... |
| 08:47 |
Dyrcona |
I visited the web staff client on a local test vm after rebuilding it and using a new, self-signed certificate. |
| 08:48 |
Dyrcona |
Firefox went to offline mode until I clicked on the info button in the location bar, cleared the old security exception, and added an exception for the new certificate. |
| 08:48 |
Dyrcona |
I think it used to go straight to "your connection is insecure" when the cert. changed. |
| 08:49 |
Dyrcona |
This is Firefox 60.0.2 on Ubuntu 18.04. |
| 16:03 |
Dyrcona |
br1bbrown / beverlyb1234 |
| 16:03 |
Dyrcona |
You know about the list of concerto users? |
| 16:04 |
Dyrcona |
It seems to be working for me after doing npm run build-prod. |
| 16:04 |
Dyrcona |
I wonder if I just got a bad build somehow, even though it said everything was OK and npm run test passed? |
| 16:05 |
idjit |
yeah, this user still works for me. |
| 16:05 |
* Dyrcona |
tries with Chromium, again. |
| 16:05 |
* idjit |
tries with firefox |
| 17:32 |
|
rlefaive joined #evergreen |
| 17:41 |
Dyrcona |
idjit: You have to accept the certificate twice if no proxy is in place with Firefox. |
| 17:41 |
Dyrcona |
Once as normal, and also for https://host.domain.tld:7682/ |
| 17:42 |
idjit |
ah, ok. i'll see about testing that out more on monday, then. |
| 17:42 |
Dyrcona |
I was seeing it more in Chromium than in Firefox just before I had to leave last time. |
| 17:43 |
idjit |
well hopefully someone can replicate it. i couldn't. gotta run though, good luck! |
| 17:44 |
Dyrcona |
I get these in Chromium, but I think they can be ignored: |
| 17:44 |
Dyrcona |
Failed to load resource: net::ERR_CERT_AUTHORITY_INVALID |
| 17:44 |
Dyrcona |
That's after accepting the cert, too. |
| 17:45 |
* Dyrcona |
avoids getting started on certificates and authorities, etc. :) |
| 17:45 |
idjit |
i don't get any ssl errors on my test instance. |
| 17:47 |
Dyrcona |
Well, I do in Chromium 66 but not Firefox 60. Everything seems to work, mostly. |
| 17:48 |
Dyrcona |
Anyway, I'm moving on to something completely different, i.e. not Evergreen. I filed a bug and I still see the behavior more or less as described. |
| 17:49 |
|
beanjammin joined #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:03 |
|
beanjammin joined #evergreen |
| 19:14 |
Dyrcona |
Don't you hate it when you swear you had a file with certain information in it, but now you can find no trace of it? |
| 19:18 |
Dyrcona |
I'm also guessing that if I deleted it, my oldest backup is likely too recent to have it. |
| 00:12 |
|
bshum joined #evergreen |
| 00:29 |
|
beanjammin joined #evergreen |
| 06:06 |
|
rlefaive joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:54 |
|
agoben joined #evergreen |
| 07:56 |
|
collum joined #evergreen |
| 08:06 |
|
bdljohn joined #evergreen |
| 09:18 |
|
yboston joined #evergreen |
| 09:21 |
Dyrcona |
Guess it is too early to harangue jeffdavis.... |
| 09:21 |
Dyrcona |
Since we upgraded to 3.0 our Overdrive integration is not working at all. |
| 09:21 |
Dyrcona |
Of course, the system I set up for testing with their test/integration site works just fine. |
| 09:21 |
Dyrcona |
overdrive-- |
| 09:22 |
Dyrcona |
Different settings in testing versus production....Lame. |
| 09:29 |
kmlussier |
Is there anyone here who could reply to the post on the code4lib list regarding Spanish-language ILSs? He specifically asked about Evergreen. |
| 09:30 |
bshum |
kmlussier: I saw that post and was contemplating a good reply |
| 09:31 |
bshum |
Or perhaps pestering terran / csharp to say something since Georgia has Spanish in their catalog :) |
| 14:06 |
kmlussier |
@dessert [someone] |
| 14:06 |
* pinesol_green |
grabs some Cookies and Cream Ice Cream for gsams |
| 14:07 |
gsams |
kmlussier++ #I think I need that right now |
| 14:15 |
berick |
more websocketd load testing. just sent 500k connect+request+disconnect combos across 5 parallel procs. no hiccups, no memory leaks. |
| 14:15 |
berick |
think it might be time for an LP for that |
| 14:18 |
csharp |
berick++ |
| 14:18 |
* csharp |
wants to test but has not found time for anything other than helpdesk & office move stuff :-/ |
| 14:19 |
Dyrcona |
berick: Have you shared any of the scripts that you're using for load tests? |
| 14:19 |
Dyrcona |
I suppose I could check the Lp entries again. |
| 14:21 |
berick |
Dyrcona: yes, they're both in the branch, sec |
| 14:21 |
berick |
http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=tree;f=src/websocket-stdio;h=3fb454ee5aaa017201b2ab2763c0fcbb2bdbf490;hb=refs/heads/user/berick/websocketd-backend |
| 15:34 |
idjit |
hello, #evergreen. i've been looking at bug 1587620 and bug 1775216. |
| 15:34 |
pinesol_green |
Launchpad bug 1587620 in Evergreen "Staff copy counts do not include peer bib copies" [Undecided,Confirmed] https://launchpad.net/bugs/1587620 |
| 15:34 |
pinesol_green |
Launchpad bug 1775216 in Evergreen "Inconsistency between client and opac availability counts for statuses with is available flag" [Medium,Confirmed] https://launchpad.net/bugs/1775216 |
| 15:34 |
idjit |
the test on 1775216 fails because of the problem noted in 1587620. |
| 15:36 |
idjit |
i have a new asset.staff_ou_record_copy_count that seems to work. should i add that to the branch on bug 1775216 (so there's just one thing to merge and that's where the test is) or should i cut a new branch for 1587620, because that's the actual problem that i was trying to fix? |
| 15:36 |
pinesol_green |
Launchpad bug 1775216 in Evergreen "Inconsistency between client and opac availability counts for statuses with is available flag" [Medium,Confirmed] https://launchpad.net/bugs/1775216 |
| 15:37 |
Dyrcona |
Just going by the descriptions, these sound like possibly the same bug just stated in different terms, or is there more the latter bug? |
| 15:43 |
kmlussier |
Dyrcona: I think they're different. The peer visibility bug has been around for many releases. The available flag bug is more recent. |
| 16:00 |
* bshum |
mumbles something about "working code wins" |
| 16:01 |
kmlussier |
idjit: Thanks for diving in an taking the chance of getting the "stern talkin' to"! |
| 16:30 |
|
khuckins joined #evergreen |
| 16:54 |
jeffdavis |
websocketd lightly tested here and working well so far, hoping to do some more thorough testing next week |
| 16:54 |
jeffdavis |
re bug 1777180 |
| 16:54 |
pinesol_green |
Launchpad bug 1777180 in OpenSRF "Wishlist: Websocketd Gateway Support" [Wishlist,New] https://launchpad.net/bugs/1777180 |
| 16:57 |
berick |
jeffdavis++ |
| 16:58 |
|
bdljohn left #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 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 |
| 08:27 |
|
bdljohn joined #evergreen |
| 09:10 |
|
jvwoolf1 joined #evergreen |
| 09:13 |
|
Dyrcona joined #evergreen |
| 09:35 |
|
kmlussier joined #evergreen |
| 09:35 |
pinesol_green |
[evergreen|Remington Steed] Docs: Minor corrections to "Borrowing items" section - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bd663dd> |
| 09:50 |
|
Christineb joined #evergreen |
| 09:50 |
|
collum joined #evergreen |
| 10:17 |
pinesol_green |
[evergreen|Bill Erickson] LP#1774427 Parse DoB dates as whole dates - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4cd44bb> |
| 10:42 |
dbs |
huh. 48 new bib records yesterday with tcn_source = '', from a mix of users and times |
| 10:44 |
dbs |
two of them are ACQ orders. I wonder if this is a z39.50 copy cataloguing thing |
| 10:46 |
dbs |
it is, in fact, every record created yesterday |
| 11:24 |
csharp |
hmm - none with "" in the last 90 days for us - I thought acq vandelay might cause it, but apparently not |
| 11:36 |
Dyrcona |
Well, while we're on the subject of vandelay and imports, none of our records are importing if they have holdings tags. |
| 11:36 |
Dyrcona |
The example I've been giving are two records with 949 tags and a holdings import profile that looks for the 949. |
| 11:37 |
Dyrcona |
The bibs don't even make it to the queue and I see no errors in the logs on my test vm. |
| 11:38 |
Dyrcona |
They say this happens in the XUL and web staff clients. I've so far only tested xul, but will try the web staff client in a moment. |
| 11:40 |
|
khuckins joined #evergreen |
| 11:41 |
kmlussier |
How do you use Vandelay without selecting a source? When I retrieve the interface, it defaults to oclc and there is no way to not select an option as far as I can tell. |
| 11:42 |
berick |
kmlussier: source vs. tcn_source |
| 12:08 |
|
jihpringle joined #evergreen |
| 12:25 |
|
jvwoolf joined #evergreen |
| 12:27 |
|
jvwoolf1 joined #evergreen |
| 12:52 |
Dyrcona |
On my test vm, I'm getting a 403 on vandelay-upload. |
| 12:53 |
Dyrcona |
With "Require all granted"! |
| 12:53 |
Dyrcona |
The tmp file is created... |
| 12:57 |
dbs |
Dyrcona: exceeding the max upload length maybe? |
| 16:55 |
Dyrcona |
https://www.brainyquote.com/quotes/lord_byron_161299 |
| 17:00 |
Dyrcona |
And with that, I'm signing out to reboot for a kernel update. |
| 17:45 |
jeffdavis |
Byron's early contributions to the development of set theory are insufficiently known. |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 02:27 |
|
annagoben joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:44 |
|
bdljohn joined #evergreen |
| 08:23 |
|
rlefaive joined #evergreen |
| 09:52 |
abneiman |
kmlussier++ # much-needed caffeine :) |
| 09:53 |
kmlussier |
Poor cesardv didn't get any caffeine in his pot of tea. :( |
| 09:55 |
abneiman |
yeah, but that tea sounds delicious though |
| 09:58 |
idjit |
does anyone happen to have a test server with concerto data handy? i've got an oddity. |
| 09:58 |
idjit |
and i'm not sure if it's just me or not |
| 09:59 |
kmlussier |
idjit: https://mlnc4.noblenet.org |
| 09:59 |
kmlussier |
Admin login is admin / evergreen123 |
| 10:00 |
idjit |
kmlussier++ # thanks! |
| 10:12 |
idjit |
hrm.. location "reserves" instead of "stacks"... i wonder if the others are there too. i'll get back to you if i learn something. i'm just glad to confirm behavior is consistent on other instances. |
| 10:16 |
|
Dyrcona joined #evergreen |
| 10:17 |
kmlussier |
Reserves is OPAC visible for BR1, so it should be showing. I don't see anything else on that record that says it's not opac visible. Also, it's not displaying in the client either, which will show things that are not opac visible. hmmm |
| 10:18 |
idjit |
fwiw, that's my patch on 1775216. i found this trying to write a pgtap test for it. the test fails since counts are still inconsistent, but for reasons other than the availability. should i add the test to the branch anyway, or wait until its passing? |
| 10:23 |
kmlussier |
idjit: Well, it appears that the test is probably working, so you could add it. But there may be another bug that needs fixing. |
| 10:24 |
kmlussier |
Also, idjit++ # Adding tests |
| 10:27 |
kmlussier |
Nothing from BR1 is displaying on that record. That seems odd. |
| 10:28 |
idjit |
in case it helps, the wayward copy ids for record 30 are 31, 531, 1031, 1531, and 2031 |
| 10:28 |
idjit |
and other records with similar situations include ids 24, 40, 93, 97, and 100. they all look to be in the same boat. |
| 10:30 |
kmlussier |
I think the call numbers may be deleted? |
| 10:40 |
idjit |
are you asking me if that sounds like the correct behavior (i have no idea), a reasonable theory for what we're seeing (that sounds about right), or asking someone else if they know what's going on? :-) |
| 10:42 |
|
yboston joined #evergreen |
| 10:42 |
kmlussier |
The 2nd. Is the a reasonable theory for what we're seeing. |
| 10:42 |
mmorgan |
kmlussier: I'm not sure that's exactly what I'm seeing on another test system. |
| 10:43 |
kmlussier |
mmorgan: Are you not seeing those types of copies being counted or are you seeing something totally different affecting the counts? |
| 10:44 |
idjit |
deleted call numbers are certainly a part of it. that accounts for all of the missing copies on record #30. |
| 10:44 |
mmorgan |
Well, first it's a 3.1 beta system, so not sure what that throws into the mix. |
| 11:02 |
mmorgan |
Indeed it is! |
| 11:03 |
miker |
kmlussier: bad data does happen in the wild, sure. I think the fix is to stop the bad data from creeping in, and provide ways to detect/repair it, rather than making accommodations for it, though. (however, idjit's patch is a fix for a bug separate from bad data. I'll be looking at it later today, tuits willing) |
| 11:05 |
kmlussier |
miker: But the pre-3.0 code apparently handled this potential scenario appropriately? Shouldn't the 3.0 plus code do the same? |
| 11:05 |
mmorgan |
I undeleted the two deleted call numbers on my test system, and the copy counts are correct now. |
| 11:05 |
kmlussier |
Actually, I should verify that the 2.12 system has the same bad data before I say that with certainty. |
| 11:06 |
* mmorgan |
runs off to check for undeleted copies on delete call numbers in the wild (production server, that is) |
| 11:06 |
miker |
I think "appropriately" may be open to question. but differently, it seems. It didn't explicitly check for the deleted flag on an intervening table, but I'd argue that's a deficiency in the previous code, and checking deleted=f is more correct |
| 11:15 |
Dyrcona |
miker: I've seen it before, too, but don't recall the problems. |
| 11:16 |
Dyrcona |
I'll undelete it in a sec. |
| 11:16 |
kmlussier |
miker: I might be misunderstanding what you said above, but I think your description above of the old code ignoring the deletedness of CNs with live copies isn't what was happening. |
| 11:16 |
miker |
I have a theory I'm testing... I wonder if the copies were accidentally deleted and then someone undeleted them in the DB directly without undeleting the CN (which was auto-deleted with the last copy) |
| 11:16 |
kmlussier |
Undeleted copies that are attached to a deleted CN do not display in the holdings list. This seems correct to me. |
| 11:17 |
Dyrcona |
select count(distinct acn.id) from asset.call_number acn join asset.copy acp on acp.call_number = acn.id and not acp.deleted where acn.deleted; |
| 11:17 |
dbs |
120 instances of acn=deleted acp=not deleted in production here |
| 11:25 |
* miker |
goes looking for the code before speaking more :) |
| 11:26 |
idjit |
what i mean is: there's more than one difference between the staff client and opac queries. asset.opac_ou_record_copy_count vs asset.staff_ou_record_copy_count. |
| 11:27 |
miker |
idjit: ok, gotcha. I looked at the tip commit and that code does include "AND NOT cn.deleted", and misremembered the previous commit ... the patron version needs to learn that part |
| 11:27 |
kmlussier |
Yes, the original report related to availability counts, but, in writing a test for that fix, idjit discovered this other issue with the delete cns |
| 11:27 |
kmlussier |
idjit++ |
| 11:28 |
miker |
since they're very related, I'm in favor of fixing both in one branch, and adding a "UPDATE asset.call_number SET deleted=false WHERE..." to the upgrade script. fwiw |
| 11:29 |
kmlussier |
+1 |
| 11:30 |
idjit |
what about the lasso and metarecord versions of these functions? |
| 14:34 |
|
JBoyer joined #evergreen |
| 14:38 |
kmlussier |
idjit: It was added with bug 1698206 and is what we now use to determine if a copy is opac visible or not. |
| 14:38 |
pinesol_green |
Launchpad bug 1698206 in Evergreen "Eliminate staged search" [Wishlist,Fix released] https://launchpad.net/bugs/1698206 |
| 14:47 |
idjit |
kmlussier: thanks. it looks like i managed to bork my data then. i'm not getting the same counts on mlnc4.noblenet.org. is it necessarily a problem if the same copy has multiple rows in asset.copy_vis_attr_cache? should that be a unique key for this table? |
| 14:48 |
idjit |
i'm curious if that first query in my paste a minute ago is expected to return anything or not. i suspect not, since those four extra records are the exact four that are making my test fail. |
| 14:56 |
idjit |
wait! it's a foreign item. ....what the heck is a foreign item, and should that be included on the copy counts? |
| 14:59 |
kmlussier |
idjit: Those are for peer bibs, which I'm not very familiar with. There is a bug related to copy counts for peer bibs that pre-dates asset.copy_vis_attr_cache. |
| 14:59 |
kmlussier |
bug 1587620 |
| 14:59 |
pinesol_green |
Launchpad bug 1587620 in Evergreen "Staff copy counts do not include peer bib copies" [Undecided,New] https://launchpad.net/bugs/1587620 |
| 15:00 |
idjit |
kmlussier++ # that's gotta be it. thanks! |
| 15:00 |
kmlussier |
idjit: I also just tried your sql query on mlnc4 and I'm getting the same results. |
| 15:01 |
idjit |
https://mlnc4.noblenet.org/eg/opac/record/24 says there are 32 copies, https://egmaster.grpl.org/eg/opac/record/93?copy_limit=50;copy_offset=0 says 31 copies. the difference is the foreign/peer one. so my test is still failing. guess i figured out which bug to work on next :-) |
| 15:02 |
idjit |
yeah, so the same copyid is allowed to show up multiple times in that table if it's a foreign/peer copy for the listed records. the concerto dataset only has the one copy that uses this. |
| 15:02 |
idjit |
the opac version of copy counts joins on the copy_vis table, but the staff version doesn't, which is why the counts are off. |
| 15:03 |
|
rlefaive joined #evergreen |
| 15:15 |
pinesol_green |
[evergreen|Cesar Velez] LP#1745422 - Add Parts column to Patron holds grids and detail view - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0da274f> |
| 15:15 |
pinesol_green |
[evergreen|Michele Morgan] LP#1745422 - Removed three commented out lines from the code and signoff. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6a41918> |
| 18:17 |
jeffdavis |
anyone have a magic spell handy for automatically killing long-running search queries? |
| 18:18 |
jeffdavis |
(I know how to manually inspect and cancel backend) |
| 18:26 |
jeffdavis |
nvm, found it |
| 18:30 |
pinesol_green |
News from qatests: Failed Log Output: osrfsys.log - Expected 3 errors but encountered 6. <http://testing.evergreen-ils.org/~live> |
| 18:37 |
|
stephengwills joined #evergreen |
| 19:49 |
|
bdljohn joined #evergreen |
| 21:07 |
|
bdljohn joined #evergreen |
| 00:25 |
|
beanjammin joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:19 |
|
agoben joined #evergreen |
| 07:48 |
|
gsams__ joined #evergreen |
| 08:58 |
|
Dyrcona joined #evergreen |
| 09:00 |
|
idjit joined #evergreen |
| 09:12 |
dbwells |
csharp: I am not aware of docs, but I'll answer best I can. 1) No third person is needed, unless you think the patch could use a third signoff. 2) If it is a bugfix and it merges cleanly, I almost always backport. If it is borderline or the merge isn't easy/obvious, I'll try to create a branch with the edited backport commit, but will leave it to the release maintainer or others to push in. |
| 09:15 |
Dyrcona |
Additional sign offs are encouraged if there are no tests or test plan. |
| 09:16 |
dbwells |
csharp: For 3.1 webstaff fixes in particular, I am going to lean in the direction of calling things bugfixes (and therefore backport) unless it is very obviously a new feature. |
| 09:16 |
|
kmlussier joined #evergreen |
| 09:17 |
Dyrcona |
I'll usually backport if it is a bugfix, the bug is targeted, and any merge conflicts are obvious to resolve. |
| 10:09 |
mmorgan |
Dyrcona: Does action_trigger.event.add_time help with the "date" of the event? |
| 10:10 |
Dyrcona |
No, because I have bills for events from before the migration being generated. |
| 10:10 |
Dyrcona |
I should have really thought this through and added a max_delay before doing the delete. |
| 10:11 |
Dyrcona |
That's what happens when you test something on a system not running action trigger cron jobs. |
| 10:12 |
Dyrcona |
I ran this last night: https://pastebin.com/34t5AY1z |
| 10:13 |
Dyrcona |
I figured I was shutting things down for an OpenSRF update, so why not? ..... :/ |
| 10:16 |
jeffdavis |
Dyrcona: action_trigger.hook has a core_type field if that helps |
| 10:40 |
jeffdavis |
a difference of 10000 units approximately |
| 10:40 |
berick |
yeah |
| 10:40 |
berick |
not simultaneous |
| 10:40 |
csharp |
I don't have a key for ccs in my test server's offline DB right now |
| 10:40 |
csharp |
what adds it? |
| 10:41 |
* csharp |
tried circulating an item |
| 10:42 |
berick |
yeah, looks like copy satuses are fleshed during checkout |
| 10:42 |
jeffdavis |
I did a checkin, then a checkout, then hit F1 and got the white screen at that point |
| 10:42 |
berick |
and at that point likely get addded to offline cache |
| 11:51 |
* kmlussier |
still can't replicate it following jeffdavis' steps |
| 11:52 |
csharp |
kmlussier: jeffdavis: I wasn't able to replicate it either :-/ |
| 11:52 |
jeffdavis |
:( |
| 11:52 |
csharp |
my test server is apparently borked, JS-wise - I keep getting partially loading UIs and "blah is not a function" errors :-/ |
| 11:53 |
csharp |
gonna blow it away and start a new one I think |
| 11:53 |
* berick |
is reminded of https://developers.google.com/web/updates/2016/06/persistent-storage |
| 11:55 |
jeffdavis |
A second person was able to reproduce the white screen with those steps in our environment. Interesting that it doesn't work elsewhere. |
| 11:58 |
|
gsams joined #evergreen |
| 12:01 |
kmlussier |
jeffdavis: I just replicated it on another server following your steps. The other environment is on 3.0 (I was previously testing on 3.1) and has production data instead of Concerto. |
| 12:02 |
kmlussier |
I wonder if I was able to replicate it more easily because, with production data, the transactions move a little more slowly, allowing me to get the timing right? |
| 12:02 |
|
jihpringle joined #evergreen |
| 12:02 |
jeffdavis |
Oh neat! Yeah, I am seeing it in production with 3.1.0 (+ many backports). |
| 12:05 |
jeffdavis |
I realize it's a little weird to be excited that something *isn't* working... |
| 12:25 |
pinesol_green |
Launchpad bug 1727557 in Evergreen 3.1 "Web Client: Download Block List causes unresponsive page with large file" [High,Confirmed] https://launchpad.net/bugs/1727557 |
| 12:26 |
berick |
but it would be simple enough to confirm if a reject() alone will allow the browser to continue... |
| 12:26 |
pastebot |
"berick" at 64.57.241.14 pasted "offline db connect promise reject" (20 lines) at http://paste.evergreen-ils.org/9096 |
| 12:27 |
berick |
jeffdavis: kmlussier: could either of you test this patch? ^-- just wondering if we can let the browser recover from the error |
| 12:27 |
sandbergja |
jihpringle++ |
| 12:27 |
sandbergja |
kmlussier++ |
| 12:27 |
sandbergja |
You are all so great! |
| 12:27 |
berick |
we still need to fix the db, of course, but maybe we can buy a little time |
| 12:27 |
kmlussier |
berick: Unfortunately, the test system where I can load patches is not the one where I was able to replicate the problem. |
| 12:28 |
* berick |
nods |
| 12:32 |
jeffdavis |
confirmed the duplicate keys error on a test server, I'll give that patch a try |
| 12:36 |
jeffdavis |
berick: I still get the white screen with that patch |
| 12:37 |
berick |
jeffdavis: ah well, thanks for testing |
| 12:37 |
jeffdavis |
on the plus side, in the test environment the error is pinpointed to lovefield.js:78 if that helps |
| 12:38 |
berick |
it does |
| 12:40 |
jeffdavis |
(that's the line immediately before the first deferred.reject() from your patch in case our line numbers are out of sync) |
| 12:41 |
berick |
oh, just recreated the error |
| 13:11 |
Dyrcona |
I'll update the bug with strace output. |
| 13:13 |
* Dyrcona |
makes absolutely certain that the jchampio branch is installed on all of the bricks as well. |
| 13:14 |
Dyrcona |
It is. |
| 13:16 |
jeffdavis |
berick: for that white screen patch, I wonder if we should notify the user somehow that their offline DB is corrupt. |
| 13:17 |
jeffdavis |
I'm getting ahead of myself though, I should test the patch first. :) |
| 13:18 |
idjit |
the patch for bug 1775216 involves a change to a database function, so i'm guessing i should add a pgtap test for it. unfortunately, while i can execute pgtap and run all the existing tests and verify they pass, i have no idea what i'm doing when it comes to writing new test cases. any guidance? |
| 13:18 |
kmlussier |
jeffdavis: berick: Yes, I was thinking along the same lines. Although I think it's a good thing to get rid of the white screens, my concern is that users happily use the system until it goes down one day, and then they are unable to use offline. |
| 13:18 |
pinesol_green |
Launchpad bug 1775216 in Evergreen "Inconsistency between client and opac availability counts for statuses with is available flag" [Medium,Confirmed] https://launchpad.net/bugs/1775216 |
| 13:19 |
kmlussier |
berick: Do you expect it will take a long time to address the long-term fix for that issue? |
| 13:19 |
* kmlussier |
also hasn't tested the patch. :) |
| 13:35 |
jeffdavis |
tested the patch, works for me, I'll update LP |
| 13:36 |
csharp |
jeffdavis++ berick++ |
| 13:40 |
Jaswinder |
Can anyone help answer my question? I am basically stuck to retrieve the id field |
| 13:44 |
Dyrcona |
The XMPP 503 errors occur in my logs prior to the upgrade to 3.0, but with much less frequency than after. |
| 14:46 |
Dyrcona |
csharp: That and possibly berick's commit to OpenSRF. |
| 14:46 |
csharp |
k |
| 14:46 |
csharp |
our spinning proc problem is not plaguing us - just an occasional annoyance |
| 14:46 |
berick |
yeah, the osrf commit probably doesn't help with the origin WS module |
| 14:47 |
berick |
probably best to revert fully back to a known state |
| 14:47 |
berick |
Dyrcona++ # testing |
| 14:47 |
csharp |
Dyrcona++ |
| 14:48 |
Dyrcona |
Hmm. There is supposed to be a dig meeting today. Was it canceled? |
| 14:49 |
jeffdavis |
I've got one spinner so far, strace shows the same constant stream of mmap/munmap that Dyrcona reported in comment #6. |
| 17:01 |
mmorgan |
That's the ideal situation! :) |
| 17:10 |
|
mmorgan left #evergreen |
| 18:08 |
|
idjit joined #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:09 |
|
stephengwills joined #evergreen |
| 19:43 |
jeffdavis |
berick++ # various good stuff |
| 01:33 |
|
RBecker joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:59 |
|
agoben joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:25 |
|
stephengwills joined #evergreen |
| 15:11 |
* Dyrcona |
forgot about the meeting.... |
| 15:11 |
gmcharlt |
not that 1725317 isn't also a concern... but I think that has the potential to turn into something that warrants a /3.1.0/, as fixing it for real would entail updating some client javascript code |
| 15:11 |
Dyrcona |
#info Dyrcona is Jason Stephenson CW MARS |
| 15:12 |
Dyrcona |
On the topic at hand, I am testing that fix in production starting tonight. |
| 15:12 |
gmcharlt |
Dyrcona++ |
| 15:12 |
gmcharlt |
and also things like bug 1729610 might call for a 3.1 |
| 15:12 |
pinesol_green |
Launchpad bug 1729610 in OpenSRF "allow requests to be queued if max_children limit is hit" [Wishlist,New] https://launchpad.net/bugs/1729610 |
| 15:17 |
gmcharlt |
ok |
| 15:17 |
miker |
anyone want to volunteer to look for (at least) perl and C libs to leverage, either that hand the caller a socket (ideally) or manage the SASL stuff for us given a socket? |
| 15:17 |
csharp |
I think 18.04 support is a reasonable goal for the next release, but I know there are higher priorities |
| 15:18 |
gmcharlt |
#action gmcharlt will do a bugfix release of OpenSRF 3.0.2, particularly upon successful testing of bug 1774703 |
| 15:18 |
pinesol_green |
Launchpad bug 1774703 in OpenSRF "Websockets processes locked at 100% CPU" [Undecided,Confirmed] https://launchpad.net/bugs/1774703 |
| 15:18 |
miker |
(and, can we target a version of ejabberd, rather than a disto release? |
| 15:18 |
gmcharlt |
#action gmcharlt will put out a call for roadmap entries for OpenSRF 3.1.0 |
| 15:36 |
berick |
how can I better expose what I'm working on? do we need a temporary repository? should I migrate my branch to a collab branch? |
| 15:36 |
csharp |
gitlab! |
| 15:36 |
berick |
it does take a little getting used to, so I'd like to avoid as many surprises as possible |
| 15:37 |
* csharp |
plans to install berick's branch on his test/dev server this week |
| 15:37 |
berick |
csharp: cool, holler if I can help |
| 15:37 |
csharp |
will do |
| 15:37 |
gmcharlt |
berick: +1 to a collab branch |
| 15:38 |
gmcharlt |
berick: and would it be useful to call a special IRC meeting? |
| 15:38 |
gmcharlt |
or a webinar from which you could do a show-and-tell? |
| 15:38 |
Dyrcona |
csharp: I tried upgrading node on an existing vm and got nothing but errors afterward. |
| 15:39 |
Dyrcona |
This was related to testing the ang6 branch. I have not had time to go back and try again. |
| 15:39 |
csharp |
Dyrcona: ah - good to know |
| 15:39 |
berick |
gmcharlt: i would be happy to participate |
| 15:39 |
gmcharlt |
ok |
| 15:42 |
JBoyer |
Did I not pullrequest it? It's done. |
| 15:43 |
gmcharlt |
ah, cool |
| 15:43 |
berick |
JBoyer: oh, cool, i missed that |
| 15:43 |
* csharp |
still hasn't arranged a good environment to test JBoyer's branch on Windows |
| 15:43 |
gmcharlt |
#info the Firefox add-on for Hatch is available |
| 15:43 |
JBoyer |
Not merged and not updated, but I've seen the printer list in both browsers simultaneously. |
| 15:43 |
JBoyer |
updated -> uploaded. |
| 16:41 |
hbrennan |
permissions experts.... what is the permission to asign access to Local > Hold Policies? I can't find it..... |
| 16:42 |
hbrennan |
search for "hold" in the lists of evergreen permissions isn't coming up with anything |
| 16:43 |
berick |
would it be ADMIN_HOLD_MATRIX_MATCHPOINT ? |
| 16:59 |
csharp |
JBoyer: it's the "no Windows nearby" issue - I'll find something to test with tomorrow :-) |
| 16:59 |
hbrennan |
berick: Thanks. Will try that. |
| 16:59 |
gmcharlt |
csharp: that thing that is both a problem... and gloriously not a problem ;) |
| 17:08 |
|
mmorgan left #evergreen |
| 17:16 |
berick |
i know what the sql is, you'd need to look at what the SQL returns and see if the rows are correctly sorted in the DB |
| 17:20 |
csharp |
berick: I can help |
| 17:21 |
csharp |
yeah, we log statements, so we can get them, but if you already know something I can run... |
| 17:22 |
berick |
csharp: it would be good for you to test whatever SQL is coming over the wire there |
| 17:23 |
berick |
just run the sql in psql and reivew the output and see if it matches the issues reported in the UI |
| 17:23 |
berick |
or if the output looks right where the UI looks wrong |
| 17:23 |
berick |
csharp++ |
| 17:24 |
berick |
huh, no way to mark an LP as done/complete/mission-accomplished short of marking it fix released. |
| 17:24 |
berick |
which is odd when there's no code |
| 17:24 |
berick |
oh well |
| 17:25 |
gmcharlt |
"this fix is too large to be contained within the confines of this tarball..." |
| 17:29 |
berick |
:) |
| 17:29 |
berick |
also known as the "You're not the boss of me" status |
| 18:10 |
berick |
oh well, will revisit tomorrow |
| 18:10 |
csharp |
berick: k - thanks! |
| 18:10 |
berick |
thanks csharp |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:59 |
|
dickreckard left #evergreen |
| 06:13 |
|
Bmagic_ joined #evergreen |
| 06:16 |
|
jeff_ joined #evergreen |
| 06:16 |
|
tsadok joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:49 |
|
collum joined #evergreen |
| 12:55 |
JBoyer |
This is a large enough problem that you're never going to have to make more than 1 correction. (unless we adopt all of the MODS versions between 3.2 and 3.6 at once and for some bizarre reason add field entries for more than one in a single upgrade script) |
| 12:56 |
Dyrcona |
Yeah, what JBoyer said. :P |
| 12:56 |
csharp |
ok - sounds sane - thanks |
| 12:57 |
JBoyer |
It's also been tested just today, if you take my meaning, heh. |
| 12:59 |
|
khuckins_ joined #evergreen |
| 13:00 |
jeffdavis |
xpath doesn't need to be updated at all so regexp_replace isn't really required, format just needs to be set correctly |
| 13:02 |
dbs |
aha, oh yay we have lots of mods32 columns too. Curse our 1.6-ish roots |
| 13:06 |
jeffdavis |
JBoyer: looks to me like a fresh install contains a mix of mods32 and mods33 cmf entries |
| 13:07 |
JBoyer |
Ok. So it is a mix, but I doubt they *need* to be different versions. |
| 13:08 |
Jaswinder |
thanks! |
| 13:10 |
JBoyer |
(I get it though, any change will need testing and do you try to go all the way to "current" and so on and etc., also tuits...) |
| 13:12 |
Jaswinder |
Dyrcona: I can call the db using the cstore but I can't find an example to filter only two columns |
| 13:14 |
Dyrcona |
Jaswinder: { "select": { "cmc": [ "name", "label"] "from" : "cmc"} # Off the top of my head. |
| 13:14 |
Dyrcona |
oops.... |
| 13:15 |
Dyrcona |
You might need to convert that to Perl hashref syntax depending on what method you use to run it. |
| 13:20 |
csharp |
Jaswinder: dbs: then my branch for bug 1764542 may be off then |
| 13:20 |
pinesol_green |
Launchpad bug 1764542 in Evergreen "Incorrect format on config.metabib_field insert results in segmentation fault" [High,Confirmed] https://launchpad.net/bugs/1764542 |
| 13:20 |
csharp |
I just did _bott_'s regexp_replace and updated the format columns for any with mods32 |
| 13:21 |
csharp |
(haven't made that change in production, just on a test server) |
| 13:21 |
Dyrcona |
jeffdavis: ^^ I think csharp meant to be talking to you. :) |
| 13:21 |
csharp |
Dyrcona: yeah - sorry Jaswinder |
| 13:22 |
|
bdljohn joined #evergreen |
| 16:38 |
|
jvwoolf left #evergreen |
| 17:03 |
csharp |
bug 1710293 is one of those where I want to help do that kind of work/cleanup, but I'm not exactly sure what to do in a couple of cases - should I just give it a go with the hope that miker or someone will review it and correct me or is it better to just leave it for someone else? :-) |
| 17:03 |
pinesol_green |
Launchpad bug 1710293 in Evergreen 3.1 "Remaining chunk/bundle work" [Medium,New] https://launchpad.net/bugs/1710293 |
| 17:07 |
miker |
csharp: max_chunk_count should def be spelled max_bundle_count, and the stuff in the ->can() tests can go away now (3.0+) ... and max_chunk_size=>0 should also change as described. I don't think there are any gotchas there (pending testing, obv) if you have the tuits to spare! |
| 17:08 |
csharp |
miker: cool - thanks - I'll give it a shot :-) |
| 17:09 |
|
mmorgan left #evergreen |
| 17:09 |
miker |
csharp++ |
| 17:32 |
gsams |
I'm excited and hopeful, even though it's like a tiny change, but I just pushed a fix. |
| 17:36 |
idjit |
is there a suite of unit tests i should be running prior to submitting pullrequests for things like bug 1724348 or bug 1743801? |
| 17:36 |
pinesol_green |
Launchpad bug 1724348 in Evergreen "Web client: set default view not sticky" [Undecided,Confirmed] https://launchpad.net/bugs/1724348 |
| 17:36 |
pinesol_green |
Launchpad bug 1743801 in Evergreen 3.0 "web client: item status list view display issues" [High,Confirmed] https://launchpad.net/bugs/1743801 |
| 18:17 |
jeffdavis |
idjit: there are some unit tests in Open-ILS/web/js/ui/default/staff/test but I don't know how well they can catch bugs like those two |
| 18:18 |
jeffdavis |
IIRC: `cd Open-ILS/web/js/ui/default/staff && npm run build && npm run test` |
| 18:19 |
idjit |
thanks! running now |
| 18:20 |
idjit |
well, at least my changes didn't break any of the existing tests. :-) |
| 18:20 |
idjit |
jeffdavis++ |
| 18:23 |
idjit |
hey, while you're here, do you remember bug 1761276? i get a new behavior as of this morning. it pulls up a blank page, with the javascript error "Uncaught TypeError: payload.statusCode is not a function". do you see similar? |
| 18:23 |
pinesol_green |
Launchpad bug 1761276 in Evergreen "Odd behaviour when clicking on title hyperlink " [High,Confirmed] https://launchpad.net/bugs/1761276 |
| 18:24 |
idjit |
(i get this when clicking the title on the "item status" page) |
| 18:28 |
jeffdavis |
I haven't seen that one. Is that on master? |
| 18:29 |
idjit |
i think so. i'm not sure, was hoping someone else could help confirm. |
| 18:30 |
|
beanjammin joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:33 |
jeffdavis |
I don't have a test env with master handy, will need to set one up first |
| 18:34 |
idjit |
ok, nevermind. i must've screwed something up this morning. i'm back on master branch now and i get the reported behavior. |
| 19:09 |
|
beanjammin joined #evergreen |
| 19:58 |
|
JBoyer joined #evergreen |
