| 02:12 |
|
sandbergja joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:02 |
|
agoben joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:47 |
|
rfrasur joined #evergreen |
| 10:46 |
csharp |
so... I spent an additional 3 hours re-upgrading to 9.6 and we're now live on that with no issues |
| 10:47 |
csharp |
planning to gather details for a bug report ASAP, but no one should upgrade to PG 10 until there's a very close look at our SQL |
| 10:49 |
berick |
csharp++ pines++ # trailblazing |
| 10:51 |
csharp |
sooo glad I did the postgres upgrade outside of the EG upgrade window next weekend |
| 10:51 |
csharp |
that would have been hell to untangle |
| 10:56 |
csharp |
the most frustrating part of the ordeal is that we've been testing 3.4 on PG 10 for *months* and have not noticed the issue at all |
| 10:57 |
csharp |
I didn't explicitly run PG unit tests, so possible it would have emerged there |
| 10:57 |
dbs |
csharp++ # thank you for taking that bullet for the rest of us |
| 10:58 |
* csharp |
tips his hat |
| 11:10 |
|
sandbergja joined #evergreen |
| 12:36 |
Bmagic |
can "@code='a' or @code='t'" become "@code='a' AND @code='t'" |
| 12:51 |
|
Dyrcona joined #evergreen |
| 12:59 |
|
collum joined #evergreen |
| 13:11 |
Dyrcona |
csharp: That Pg 10 thing is a known issue, and we have fixed all of the functions that have turned up in testing. Doesn't mean we haven't missed some. Fixes may also not have been backported. |
| 13:19 |
Dyrcona |
Bmagic: Do you want only fields with both the subfield a and t to show up? |
| 13:20 |
Bmagic |
Dyrcona: sure, and I could make an additional definition for just one of them (at another time) |
| 13:20 |
* dbs |
was wondering if the PG10 thing was a difference between the experience of upgrading and a fresh install |
| 13:22 |
Dyrcona |
PG11 and PG12 also seem ok in my very limited tire kicking. |
| 13:22 |
dbs |
Right, I would expect a fresh install to work. But it's the upgrading of an existing system that might be tricky |
| 13:23 |
Dyrcona |
Yeahp. I'm not sure we've made it very clear what functions you have to replace, either. |
| 13:23 |
Bmagic |
Dyrcona: Simple enough. But will the entry be the two fields concatenated? A la metabib.browse_entry.value. - I was planning on setting this up on a test server and trying it out, so no worries |
| 13:23 |
Bmagic |
dbs: I agree, I think it's the upgrade |
| 13:24 |
Dyrcona |
I know it's the upgrade. :) |
| 13:24 |
Bmagic |
:) |
| 13:50 |
Dyrcona |
csharp: https://bugs.launchpad.net/evergreen/+bug/1820339 |
| 13:50 |
pinesol |
Launchpad bug 1820339 in Evergreen "Postgres 10 support: Vandelay Edition" [Medium,Fix released] |
| 13:51 |
Dyrcona |
But, yeah.... |
| 13:51 |
JBoyer |
Speaking of bug numbers, if anyone wanted to test bug 1858701 it's real simple and can lead to some really confusing error messages. |
| 13:51 |
pinesol |
Launchpad bug 1858701 in Evergreen "URL modification with regular expressions can lead to 403 Forbidden errors" [Undecided,New] https://launchpad.net/bugs/1858701 |
| 13:51 |
JBoyer |
well, unexpected, anyway. |
| 13:52 |
jeff |
Is anyone here aware of useful workflows for inspecting items on/after checkin, inspecting for missing pieces before capturing for a hold or re-shelving them? |
| 13:54 |
jeff |
(or use a dedicated workstation where it's "normally on", etc) |
| 13:55 |
jeff |
Other options include "suppress holds and transits" on the initial checkin. Similar issue there: need to turn it on/off, not simple to "oops, scratch that!" if you forget and capture something to available-for-pickup. |
| 13:56 |
jeff |
Persistent copy alerts with a next-status on checkin are... almost it? I don't think the workflow/features are quite there, but it's potentially promising. |
| 13:56 |
JBoyer |
csharp: yeah, that should be fine. The PG10 changes were tested to be compatible with at least 9.6 (no reason they shouldn't be fine farther back as well) |
| 13:57 |
JBoyer |
But farther back doesn't matter since you can't upgrade to that point without 9.6+ anyway, so it's good. ;) |
| 13:58 |
csharp |
right |
| 13:59 |
csharp |
I think I made the right 1:00 a.m. call :-) |
| 17:28 |
berick |
Bmagic: string-join((//marc:datafield[@tag='810']/marc:subfield[@code='a'], //marc:datafield[@tag='810']/marc:subfield[@code='t']), " ") |
| 17:29 |
Bmagic |
berick++ |
| 18:00 |
Bmagic |
I'm calling this a bust. But FYI, the string-join and concat functions (with parentheses in the right places) still throw an error during ingest "invalid XPath expression" function metabib.reingest_metabib_field_entries(bigint,boolean,boolean,boolean,boolean,integer[]) line 49 at FOR over SELECT rows |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:04 |
|
sandbergja_ joined #evergreen |
| 19:12 |
|
cmalm joined #evergreen |
| 19:39 |
|
sandbergja_ joined #evergreen |
| 00:12 |
|
sandbergja joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:38 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:34 |
|
csharp joined #evergreen |
| 08:13 |
|
Dyrcona joined #evergreen |
| 08:27 |
csharp |
dbs: either Terran (out today) or I can help with carousel setup - that was early November, so I'm a bit rusty, but we definitely have it running the way we want on a test server |
| 08:28 |
csharp |
we have an office open house this morning and I'm kind of here and there all day, but I'll check in to see if you have a question/issue I might be able to help save time on |
| 08:48 |
|
mmorgan joined #evergreen |
| 08:50 |
|
mantis1 joined #evergreen |
| 08:50 |
Dyrcona |
Ah, well. I guess yesterday's test was a bust. The log settings filled the 30GB of space available in / on my test vm. |
| 08:52 |
Dyrcona |
Amazingly, it didn't crash. |
| 08:57 |
Dyrcona |
Same data as production, though, and from what I can tell, the same patron was causing a problem. |
| 08:58 |
JBoyer |
logs cranked up to debug I suppose? |
| 09:01 |
Dyrcona |
Well, actually, I truncated it to 0, rather than rm it. |
| 09:02 |
JBoyer |
I suppose if it's a single patron that causes the issue you could invalidate a bunch of the events and just reset the biggest groupings, maybe it will fail faster? (OR it won't fail at all because Heisenbugs) |
| 09:06 |
Dyrcona |
If I leave the problem patron's events in collected state and set the other collected events t pending, the others succeed. |
| 09:06 |
Dyrcona |
I was just trying to confirm on my test sever what I concluded in bug 1858471, though I started before I filed the bug. |
| 09:07 |
pinesol |
Launchpad bug 1858471 in Evergreen "Events with large amount of data can crash action_trigger_runner.pl" [Undecided,New] https://launchpad.net/bugs/1858471 |
| 09:09 |
Dyrcona |
Turns out that I didn't need the debug log level to see what the problem. |
| 09:09 |
JBoyer |
Ah, right. I see it in there now. (the 3037383 byte message line) |
| 10:32 |
|
mantis2 joined #evergreen |
| 11:16 |
mmorgan |
Could an upgrade from 3.2.8 to 3.3.5 disrupt printer settings in the web client? |
| 11:18 |
mmorgan |
We've had reports of lost margin settings for receipt printer and inability to print to same. |
| 11:26 |
csharp |
mmorgan: we're testing 3.4 and have an issue report concerning receipt printing not working correctly |
| 11:26 |
csharp |
"From ARL: Chrome; hold slip did not automatically print or give the option to print on some computers, even with Auto-Print modifier on check-in screen. For the ones that did, format did not reflect the 4 letters last name - 4 digits card format. ---> (Note that they probably didn't have their custom print templates installed on their testing workstations)" |
| 11:27 |
csharp |
the parenthetical part was probably from Terran explaining what she thinks caused part of the issue |
| 11:27 |
csharp |
two of our staff here confirmed the issue, but I haven't looked closely yet |
| 11:28 |
csharp |
she thinks bug 1858118 is possibly related, so we've applied that fix to the test server and haven't had a chance to test |
| 11:28 |
pinesol |
Launchpad bug 1858118 in Evergreen "AngJS Always Tries To Use Hatch For Printing" [Critical,Fix committed] https://launchpad.net/bugs/1858118 |
| 11:30 |
* dbs |
wonders if his is the first site on 3.4 in production |
| 11:31 |
dbs |
If printing via Hatch, berick's suggestion of applying printer settings to each kind of printer (not just Default and Label) resolved some problems for us |
| 17:41 |
Bmagic |
@later tell mmorgan: sure |
| 17:41 |
pinesol |
Bmagic: The operation succeeded. |
| 17:59 |
dbs |
Bmagic: Yes, I get it. If a library only copy catalogued from a single source ever, sure. Or maybe if every library used UUIDs for their 001 to (probably) avoid conflicts |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:00 |
dbs |
That said, if someone wants to search for an OCLC number, identifier|oclcnum: works really well if the 001 and 003 identify that it comes from OCLC, and then gets moved predictably into 035 as (OCoLC)######### |
| 18:02 |
dbs |
But that would require searching the regular catalogue separately from Z39.50. (I don't think OCLC puts (OCoLC)######## into their own 035) |
| 18:28 |
dbs |
Also found out today that either the Norton Safe Web or IBM Trusteer Rapport extensions for Chrome subtly break the web staff client (symptom: trying to open the Reports interfac results in an ACTOR_USR_NOT_FOUND error dialogue, and console shows that an http translator call gets truncated) |
| 00:20 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:53 |
|
sandbergja joined #evergreen |
| 06:58 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 08:58 |
pinesol |
Launchpad bug 1781274 in Evergreen 3.4 "Web Client: Transactions Do Not Always Close When Bill Fully Paid" [Undecided,Confirmed] https://launchpad.net/bugs/1781274 |
| 09:23 |
|
yboston joined #evergreen |
| 09:32 |
|
jvwoolf joined #evergreen |
| 09:38 |
Dyrcona |
So, testing here at CW MARS indicates that the aged billing/payments feature breaks our reports. We're looking into possible resolutions on our end, including possibly deleting the code from our local branch. Expect a Lp bug for discussion to pop up soonish. |
| 09:39 |
Dyrcona |
I realize that it may be too late to modify the feature globally. |
| 09:42 |
JBoyer |
breaks how? And given the timing, I assume it's somehow causing end of year report problems? |
| 09:44 |
Dyrcona |
JBoyer: jamundson has the details, and I expect he'll summarize it on a Lp bug. We have some pretty sophisticated financial reports and we use a pretty aggressive timeline for aging circulations, 7 days, so I think it is more than end of year stuff. |
| 17:23 |
berick |
Bmagic: there's a Makefile.install target specifically for standalone DB servers |
| 17:24 |
Bmagic |
gotcha, I was reading it wrong I guess. |
| 17:24 |
berick |
postgres-server-ubuntu-xenial, postgres-server-ubuntu-xenial-10, etc. |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:30 |
|
csharp joined #evergreen |
| 19:50 |
|
jvwoolf joined #evergreen |
| 20:21 |
dbs |
Trying to create a carousel for the first time. Gave myself the ADMIN_CAROUSEL and ADMIN_CAROUSEL_TYPE permissions, clicked New Carousel, filled out the fields for a Newly Cataloged carousel, and |
| 06:00 |
|
Bmagic joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:34 |
|
agoben joined #evergreen |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 07:27 |
|
rfrasur joined #evergreen |
| 12:25 |
jeff |
SELECT first_given_name, ... seventh_given_name FROM actor.org_unit... |
| 12:26 |
berick |
alter table actor.usr rename column super_user to is_protector_of_the_realm; |
| 12:26 |
|
sandbergja joined #evergreen |
| 12:28 |
mmorgan |
dbs: Did your checkout with duration 168:00:00 give you the correct due date/time? |
| 12:29 |
* mmorgan |
is attempting to test and is getting a due date/time of 2020-01-10 23:59:59-05 |
| 12:29 |
jeff |
berick++ |
| 12:41 |
dbs |
mmorgan: let me double check |
| 12:41 |
dbs |
on the long-name issue, I opened bug # 1858225 (and included a screenshot, although not nearly as fun as bshum's yodawg) |
| 12:41 |
* mmorgan |
is testing on a 3.4.1 system |
| 12:42 |
dbs |
mmorgan: I had checked in the staff client and the checkout gave a due date of 2020-01-10 for our 168:00:00, I'll check in the database for the specific time |
| 12:43 |
|
mantis2 joined #evergreen |
| 12:45 |
|
mantis1 joined #evergreen |
| 14:03 |
Dyrcona |
Is the order of the id column in the actor.org_unit_custom_tree_node table important? We want to add 2 new org_units and we had trouble with the admin interface on training, so I thought that I'd do the update in the database. |
| 14:07 |
berick |
Dyrcona: I haven't confirmed, but given the sibling_order column, I would expect the ID to be generally ignored. |
| 14:08 |
|
collum joined #evergreen |
| 14:08 |
Dyrcona |
berick: That's my assumption, too. I'll test this on a vm before I do it in production. Thanks! |
| 14:10 |
Dyrcona |
I asked because it looks like the table is rebuilt more or less in order every time it is updated via the staff client. |
| 14:14 |
dbs |
mmorgan++ # thank you |
| 14:29 |
Dyrcona |
berick: Seems to work. |
| 17:01 |
|
mmorgan left #evergreen |
| 17:04 |
|
sandbergja joined #evergreen |
| 17:37 |
jeffdavis |
Are there any circumstances where it is correct for a circ to remain open (xact_finish is null) when the circ has a checkin time and there is no balance owed? |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:12 |
|
dbwells_ joined #evergreen |
| 18:23 |
|
yar joined #evergreen |
| 19:07 |
|
cmalm joined #evergreen |
| 01:25 |
|
sandbergja joined #evergreen |
| 05:45 |
|
awitter joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:38 |
|
agoben joined #evergreen |
| 07:05 |
|
rjackson_isl joined #evergreen |
| 07:22 |
|
rfrasur joined #evergreen |
| 09:11 |
Dyrcona |
Well, I wasn't think of that specifically, but it would cause problems. I just thought maybe somebody changed something and autogen.sh wasn't run. |
| 09:13 |
Dyrcona |
Otherwise, I'm not sure why this would suddenly start happening, unless some service needs a restart/crashed. |
| 09:14 |
Dyrcona |
Maybe a corrupted fm_IDL somewhere? Disk issue? |
| 09:15 |
Dyrcona |
I should focus on the test that I'm setting up. I just made a mistake in the crontab that's part of the test. |
| 09:15 |
dbs |
Dyrcona: yes, focus on your stuff, I've got this working-ish for now |
| 09:19 |
Dyrcona |
Well, the mistake was no big deal, I just forgot to add some options and the &>> redirect on the run-pending runner. |
| 09:20 |
Dyrcona |
I'm trying to emulate production, though I think my main problem is just the number of events we're processing. |
| 10:30 |
Dyrcona |
berick: I'm seeing other events get stuck in collected state in production. I don't my problem necessarily has anything to do with chained events. I've got a coupe of 28 day mark lost events that are in collected state. I think I need to get down to the reason for the jabber client disconnections. |
| 10:31 |
berick |
Dyrcona: well mark lost is another chained A/T |
| 10:31 |
berick |
did you see any improvement in the autorenew after the patch? |
| 10:32 |
Dyrcona |
Well, maybe, they didn't blow up on a test server, but our 2-day courtesy notices did. |
| 10:32 |
Dyrcona |
I'm doing a more thorough test today with a bunch of things emulating production. |
| 10:32 |
Dyrcona |
I have the same, but more, data on a slower machine and slower db server. |
| 10:33 |
berick |
well, i can't comment on the predues, but if the patch fixes autorenew, then a similar patch might help mark-lost |
| 10:35 |
Dyrcona |
berick: OK, I'll take a look. I'm not running those on this test. |
| 10:36 |
Dyrcona |
Also, is anyone else having to fix dates in your manually entered db queries this morning? I'm still typing 2019. :) |
| 10:38 |
* mmorgan |
hasn't had occasion to type a date yet, but 2020 does look odd down in the corner of my computer screen :) |
| 10:45 |
Dyrcona |
:) |
| 13:41 |
Dyrcona |
I thought OpenSRF had an error message for that, but I'm not finding it. |
| 13:41 |
|
cmalm joined #evergreen |
| 13:43 |
|
jihpringle joined #evergreen |
| 13:53 |
dbs |
yay, over on our test server getting "egCore.hatch.getWorkstations is not a function" console error at the web staff client login prompt. and getWorkstations() is clearly defined in eg2/src/app/core/store.service.ts - sigh |
| 13:53 |
dbs |
at least it's our test server. |
| 13:54 |
berick |
dbs: one of those is eg2, one is eg. |
| 13:54 |
Dyrcona |
Aint' web development fun? |
| 13:55 |
Dyrcona |
Ain't software development fun? |
| 14:52 |
Dyrcona |
:) |
| 14:53 |
dbs |
Dyrcona: did not know about the "Empty Cache and Hard Reload" option! |
| 14:54 |
Dyrcona |
It's only there in Chrome with the dev tools enabled. |
| 14:54 |
Dyrcona |
I find it very handy when testing. |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:07 |
dbs |
I guess we should document this expectation for now, and then work on fixing it so it's no longer necessary? |
| 15:09 |
|
jvwoolf joined #evergreen |
| 16:51 |
pinesol |
Launchpad bug 1858118 in Evergreen "AngJS Always Tries To Use Hatch For Printing" [Critical,New] |
| 16:52 |
mmorgan |
Okay, thanks! |
| 17:04 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:02 |
|
sandbergja joined #evergreen |
| 18:19 |
|
abowling1 joined #evergreen |
| 18:21 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:04 |
|
rjackson_isl joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 09:01 |
|
mantis1 joined #evergreen |
| 10:31 |
berick |
might be worth teaching them to wait for the response from their open-ils.trigger.event.autocreate calls |
| 10:34 |
pastebot |
"berick" at 168.25.130.30 pasted "AutoRenew.pm waits for event creation" (23 lines) at http://paste.evergreen-ils.org/10117 |
| 10:34 |
berick |
something like that ^- |
| 10:35 |
Dyrcona |
I can try that, but I've almost never had this happen on a test environment. |
| 10:37 |
mmorgan |
fwiw, I'm not seeing the same issues as Dyrcona, but the highest number of autorenewal events we've had in a day is just under 7000 |
| 10:38 |
Dyrcona |
mmorgan: Get that many on a slow day. :) |
| 10:42 |
Dyrcona |
Meh.... lineendings-- |
| 10:45 |
Dyrcona |
I have a script to fix PO JEDI issues. |
| 10:46 |
Dyrcona |
I think A/T is the wrong mechanism for some of these things. If it is something that should be generated regularly a plain old cron job should do it. |
| 10:47 |
Dyrcona |
I can see A/T for things triggered by user actions, like PO JEDI, for instance. |
| 10:48 |
Dyrcona |
I'm going to run a daily action trigger runner on a test vm with --verbose and --debug-stdout |
| 10:50 |
berick |
A/T jedi's been replaced, of course. /me still needs to make that migration |
| 10:50 |
Dyrcona |
Um, yeah, I guess it has. :) |
| 10:50 |
Dyrcona |
We were testing the replacement, but lost the configuration when I refreshed the training database. |
| 10:56 |
Dyrcona |
I imagine that this will take a few hours. |
| 10:56 |
Dyrcona |
I should test it again on Thursday. |
| 10:59 |
Dyrcona |
I'm running it with berick's patch, I suppose I should run it without and then with.... |
| 11:00 |
Dyrcona |
So far, though, nothing has blown up. :) |
| 11:01 |
Dyrcona |
Or, maybe it has. syslog hasn't changed in about 6 minutes. |
| 13:12 |
* Dyrcona |
is a bit slow in the brainbox today. |
| 13:18 |
Dyrcona |
So, it looks like 26,445 courtesy notices got stuck in 'collected' this morning. |
| 13:18 |
Dyrcona |
I'll update them to pending in production and see what happens in about 10 minutes. |
| 13:21 |
Dyrcona |
Looks production has about half as many as my test system. I suppose the difference are the ones that were checked in between midnight Sunday and this morning. |
| 13:21 |
Dyrcona |
Well, midnight Saturday to Sunday. |
| 13:22 |
Dyrcona |
Looks like the 10,694 autorenewal and notice events processed OK. |
| 13:41 |
Dyrcona |
Hmm. The generic run pending did not pick them up. |
| 14:34 |
Dyrcona |
So, there's an interplay going on here. The daily a/t runner creates the autorenewal notice events but our twice hourly run-pending runner runs them. Could it be a timing issue? |
| 14:35 |
Dyrcona |
Seems like I've had parts of this monologue before... |
| 14:44 |
|
khuckins joined #evergreen |
| 14:46 |
Dyrcona |
So, test for Thursday morning: start Daily-PD-2, then start daily, then run a generic run-pending every half hour or so. |
| 14:46 |
Dyrcona |
With --verbose and --debug-stdout on all three. |
| 16:01 |
|
sandbergja joined #evergreen |
| 16:38 |
|
book` joined #evergreen |
| 18:01 |
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:07 |
|
rjackson_isl joined #evergreen |
| 08:07 |
|
stephengwills joined #evergreen |
| 08:22 |
|
stephengwills joined #evergreen |
| 14:45 |
dbs |
Well, I just installed the 8 different add-ons I use in Firefox into a clean FF profile and can't trigger the error |
| 14:46 |
dbs |
(Bitwarden, Cookie Autodelete, EZProxy Redirect Foxified, Firefox Multi-Account Containers, GNOME Shell integration, Grammalecte[fr], uBlock Origin, and Zotero Connector) |
| 14:48 |
Dyrcona |
Of those, I use GNOME Shell Integration and uBlock Origin. |
| 14:50 |
dbs |
was inspecting the stored user preferences under Administration -> Workstation but I don't really see how that would make a difference |
| 14:51 |
dbs |
ah well, hopefully it's just something weird & truly unique with this workstation |
| 14:53 |
|
khuckins joined #evergreen |
| 15:18 |
dbs |
oh man. so I'm using Container Tabs in Firefox, and had been testing in a Work container tab |
| 15:18 |
dbs |
for "fun", I created a new container tab called "Testing" and used that to register a new workstation and test MARC Batch Edit |
| 15:19 |
dbs |
and of course it shows all of my record buckets (also called containers, just to confuse things further with overlapping terminology) |
| 15:21 |
dbs |
so... somehow the workstation inside one particular category of container tabs gets that XHR response wrong unless I use network tools to disable caching |
| 15:21 |
dbs |
and I can't reproduce it even within the same browser (as Firefox containers separate cookies & localstorage, etc, from other containers) |
| 15:22 |
Dyrcona |
So, don't do that? |
| 15:24 |
jeff |
i remain intrigued. it sounds like there isn't a reliable way to reproduce the issue? |
| 15:25 |
jeff |
but the nature of the oddness is... puzzling. |
| 15:38 |
Dyrcona |
OK. Fair enough. I was thinking maybe don't use the container tabs. |
| 15:38 |
dbs |
jeff: yeah, I've tried matching up as many configuration bits as I can and can't reproduce it outside of this one container |
| 16:21 |
|
sandbergja joined #evergreen |
| 16:47 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live//archive/2019-12/2019-12-30_16:00:03/test.7.html> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:15 |
pinesol |
[evergreen|Mike Risher] lp1855931 wrap text for wide Angular eg-grid column headers - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fe8a465> |
| 17:15 |
pinesol |
[evergreen|Galen Charlton] LP#1855931: (follow-up) make grid filter control cells wrap as well - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9077cbc> |
| 17:17 |
|
berick joined #evergreen |
| 17:48 |
Bmagic |
for small Evergreen patches that introduce a new row into a table, is a pgtap test required? To test that the row exists? |
| 17:49 |
Bmagic |
(Example: AutoRenew patch did not have a pgTAP to test AT hook row) |
| 17:51 |
pinesol |
[evergreen|lfloyd] DOCS: LP 1767378 Work Log documentation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8296e8c> |
| 17:51 |
pinesol |
[evergreen|lfloyd] Docs: fixed a spacing issue - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=593a93a> |
| 17:51 |
pinesol |
[evergreen|Jane Sandberg] Docs: LP1767378 follow up: adding manual anchor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7ac78d5> |
| 17:51 |
pinesol |
[evergreen|Jane Sandberg] Docs: Fixing asciidoc syntax so fop doesn't complain about staff client admin manual - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2cd4053> |
| 18:07 |
Dyrcona |
Bmagic: Well, obviously, we don't require a test for that, but adding a test would be highly encouraged, at least by me. |
| 18:08 |
Dyrcona |
Retroactively adding tests for the auto-renew feature would make a decent, bite sized bug. Perhaps I'll open one tomorrow. |
| 18:16 |
Dyrcona |
Anyway, I should have signed out a while ago. Catch you all again, tomorrow! |
| 18:41 |
|
abowling1 joined #evergreen |
| 18:59 |
|
abowling joined #evergreen |
| 02:26 |
|
cmalm joined #evergreen |
| 02:51 |
|
cmalm joined #evergreen |
| 02:59 |
|
cmalm joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:20 |
|
abowling1 joined #evergreen |
| 07:28 |
|
sandbergja joined #evergreen |
| 07:51 |
|
sandbergja joined #evergreen |
| 14:25 |
|
sandbergja joined #evergreen |
| 15:02 |
|
sandbergja joined #evergreen |
| 15:09 |
|
cmalm joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 22:16 |
dbs |
Getting a weird thing on rel_3_4 in MARC Batch Edit where the containers aren't being fetched for the requested user because the open-ils.actor.container.retrieve_by_class.authoritative returns ACTOR_USER_NOT_FOUND |
| 22:19 |
dbs |
But if I disable cache and reload the page, the request succeeds. Weird thing is the requests are almost identical, except for the user ID |
| 22:20 |
dbs |
in the cache-enabled mode, the user ID is actually the aou ID for the workstation (or possibly the home OU of the user), whereas in the cache-disabled mode it's the expected user's ID |
| 00:29 |
|
sandbergja_ joined #evergreen |
| 02:48 |
|
sandbergja_ joined #evergreen |
| 03:15 |
|
sandbergja_ joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:39 |
|
agoben joined #evergreen |
| 08:33 |
|
Dyrcona joined #evergreen |
| 08:42 |
|
mantis1 joined #evergreen |
| 09:40 |
rfrasur |
dbs: congratulations!! |
| 11:13 |
jeffdavis |
This article claims to have an improved algorithm for sorting LC call numbers: https://ejournals.bc.edu/index.php/ital/article/view/11585 |
| 11:14 |
jeffdavis |
It specifically mentions shortcomings of library-callnumber-lc, which appears to be what EG uses |
| 11:19 |
dbs |
Although it lists the Perl version in the table, the text only mentions the Python version. So... unsure. |
| 11:20 |
|
drigney joined #evergreen |
| 11:20 |
|
miker joined #evergreen |
| 11:21 |
|
alynn26 joined #evergreen |
| 11:23 |
dbs |
Would have been nice if they had contributed some failing tests to library-callnumber-lc so it could be fixed! |
| 11:23 |
* dbs |
also notes that https://github.com/scodepress/shelfreader/tree/master/tests doesn't have any real tests |
| 11:27 |
dbs |
they also could have credited Dan Wells and Bill Dueber instead of "Library Hackers" given the copyright statement in https://github.com/libraryhackers/library-callnumber-lc/tree/master/perl/Library-CallNumber-LC/README |
| 12:17 |
|
Christineb joined #evergreen |
| 12:27 |
|
sandbergja_ joined #evergreen |
| 12:29 |
|
miker joined #evergreen |
| 13:14 |
|
jweston joined #evergreen |
| 13:21 |
|
agoben joined #evergreen |
| 13:49 |
|
sandbergja_ joined #evergreen |
| 14:34 |
dbs |
Hmm. Except now to figure out why trying to save an edited record turns up a "Failed to save record: {{error}}" message |
| 14:43 |
|
remingtron_ joined #evergreen |
| 14:43 |
dbs |
Found an issue with the database schema by checking the logs. |
| 15:48 |
|
mantis1 left #evergreen |
| 15:53 |
dbs |
Next challenge: figuring out why I only see the leader of a record when I try "Edit and import" in the Z39.50 import screen, but I can click Import and then go to the record to edit the full thing |
| 15:54 |
dbs |
(and I do have bug # 1830923 in my branch, which is tracking current rel_3_4) |
| 15:54 |
Dyrcona |
bug 1830923 |
| 15:54 |
pinesol |
Launchpad bug 1830923 in Evergreen 3.3 "MARC import lacks ability to view and edit incoming MARC record" [High,Fix committed] https://launchpad.net/bugs/1830923 |
| 15:55 |
Dyrcona |
We have 3.4.1 on a training system, but I don't know if anyone has attempted any cataloging yet. |
| 15:59 |
Dyrcona |
dbs: You're running Pg 9.6 on the database server? |
| 15:59 |
dbs |
Dyrcona: yep |
| 16:00 |
dbs |
Strange thing is, on our testing system which only has commits up to end of November (thus missing the commits that were supposed to resolve # 1830923)... Edit then Import works |
| 16:07 |
Dyrcona |
OK. We're on 3.4.1, so only up to the end of October. |
| 16:08 |
* Dyrcona |
prepares to head out for the day. |
| 16:09 |
dbs |
Have a good one! |
| 16:09 |
Dyrcona |
You, too. Hope you figure this out. |
| 16:32 |
|
jvwoolf left #evergreen |
| 17:05 |
|
sandbergja_ joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:17 |
|
abowling1 joined #evergreen |
| 18:33 |
|
abowling joined #evergreen |
| 20:17 |
|
phasefx_ joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:53 |
|
remingtron_ joined #evergreen |
| 06:58 |
|
agoben joined #evergreen |
| 07:02 |
|
rfrasur joined #evergreen |
| 10:20 |
nfBurton |
Just click on the top nav bar before hitting the hotkey. We are just finishing RFID enabling our library with PV Supa products |
| 10:20 |
jeff |
yes, galen had a candidate fix for that which I was looking at the other day, as part of bug 1437106 |
| 10:20 |
pinesol |
Launchpad bug 1437106 in Evergreen "keyboard shortcuts in the web staff client" [Undecided,Confirmed] https://launchpad.net/bugs/1437106 |
| 10:21 |
jeff |
and yes, there is the "just click a menu / navbar area before pressing the hotkey" workaround, but I would like to work to make that no longer necessary. |
| 10:22 |
jeff |
mostly because it fails my absurdity test. i feel absurd telling someone about the required workaround. :-) |
| 10:22 |
Dyrcona |
If you want "hot keys" for everything, you don't want a browser-based application, just repeatin' myself, I know..... |
| 10:22 |
dbs |
nfBurton: right, the issue here is that the Bibliotheca software wants F1 / F2 for its own use, but the web staff client is trapping them first |
| 10:23 |
Dyrcona |
Actually, you probably want a GNU Emacs mode. :) |
| 17:18 |
Dyrcona |
:) |
| 17:37 |
|
sandbergja_ joined #evergreen |
| 17:38 |
|
abowling left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:06 |
|
Dyrcona joined #evergreen |
| 21:33 |
* dbs |
is so happy to see people talking about password resets |
| 21:34 |
dbs |
Oh, for the logs, i was able to resolve the Bibliotheca SmartStation "how do we get the barcodes into the web staff client?" issue |
| 00:44 |
|
sandbergja_ joined #evergreen |
| 04:19 |
|
serflog joined #evergreen |
| 04:19 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:56 |
|
agoben joined #evergreen |
| 07:11 |
|
Dyrcona joined #evergreen |
| 08:02 |
|
rfrasur joined #evergreen |
| 08:13 |
rhamby |
every day qa tests succeed a non-denominational spirit entity gets it's wings |
| 08:13 |
alynn26 |
lol |
| 08:15 |
|
rjackson-isl-hom joined #evergreen |
| 08:17 |
|
mantis1 joined #evergreen |
| 14:16 |
jeff |
blongwel: were the items checked in with the checkin modifier to retarget local holds? were the transits to another library, or to the checkin library (a la "capture local holds as transits")? |
| 14:16 |
jeff |
blongwel: and, what version of Evergreen? |
| 14:25 |
Dyrcona |
I'm pretty sure there's a Lp bug for this already, but damned if I can find it: I just encountered a situation where paying off bills on 8 circulations set xact_finish on all but 1 of the transactions, and they were all renewed just before paying the bills. |
| 14:28 |
Dyrcona |
Renewal actually generated the bills, since I haven't run the fine generator on this test system. |
| 14:33 |
jeff |
doesn't ring a bell. anything (else) unusual about the one transaction? |
| 14:34 |
jeff |
renewal operation completed before the bills were paid? |
| 14:34 |
jeff |
fine generation on checkin (renewal) doesn't kick off anything async in the background, does it? |
| 14:58 |
Dyrcona |
blongwel: I don't think the hold_targeter is at issue, though it might be. We run ours every 15 minutes. |
| 14:58 |
Dyrcona |
mmorgan++ I knew there had to be a bug, but Lp search is terrible. |
| 14:58 |
mmorgan |
I run across that occasionally, too, usually comes to light when staff try and delete a patron record. |
| 15:02 |
Dyrcona |
Well, I found it while looking into a previous patron's circulation being aged for an item after it was renewed to the current patron. I had data from before and was seeing what happened on my test system, so thought I'd "pay" the bills, too. |
| 15:02 |
Dyrcona |
And, I think what I was looking into could be considered a bug, depending on your perspective. |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:04 |
Dyrcona |
It's bugs all the way down. :) |
| 16:39 |
|
khuckins joined #evergreen |
| 16:52 |
|
sandbergja_ joined #evergreen |
| 17:00 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:06 |
|
Dyrcona joined #evergreen |
| 19:09 |
|
cmalm joined #evergreen |
| 19:39 |
|
csharp_ joined #evergreen |
| 05:10 |
|
dbs joined #evergreen |
| 05:10 |
|
berick joined #evergreen |
| 05:55 |
|
remingtron_ joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:19 |
|
rfrasur joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 14:17 |
|
khuckins joined #evergreen |
| 14:26 |
jeffdavis |
As much as I dislike npm, I don't know if it's substantially worse on security etc than any other tools/libraries that we use. |
| 14:27 |
Dyrcona |
I think it is worse than apt, but I have little proof. There's a real problem of trust, and I trust npm much less than I do apt. |
| 14:28 |
Dyrcona |
Also, I think I understand why chromium and firefox were added to the distro *-developer Makefile.install targets, but I'm not so sure I like that, either. If I'm installing via git in production, which I do, and I'm not gonna run tests, those packages are dead weight. |
| 14:29 |
Dyrcona |
Not to mention all of the dependencies on those packages. |
| 14:30 |
Dyrcona |
I guess that's yet-another-local-patch-branch to maintain..... |
| 14:37 |
Dyrcona |
I thought we jumped to Node v12 lately? Is that just in master? |
| 14:37 |
berick |
for ang8 |
| 14:37 |
Dyrcona |
berick++ # I was just about to compare 3.4.1 and master. |
| 14:41 |
Dyrcona |
Am I right that upgrading npm breaks the Evergreen install process? |
| 14:41 |
jeffdavis |
The browsers were added because they were the best alternative for running tests. There was some discussion about separating out a -tester target but you want devs to run tests; maybe there should be a -developer-minimal target or something instead to allow installing from git without the test stuff. |
| 14:43 |
Dyrcona |
jeffdavis: Yes, that's my understanding, and I didn't say much during the discussion. I'm not sure that I want a new dependency target, so I'll live with it for now. |
| 14:44 |
Dyrcona |
Hmm... could be a *-git target that is made a requirement of the *-developer targets..... |
| 15:39 |
|
gerlevi joined #evergreen |
| 15:58 |
|
jvwoolf joined #evergreen |
| 16:22 |
|
sandbergja_ joined #evergreen |
| 17:03 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 22:13 |
|
cmalm joined #evergreen |
| 22:14 |
|
sandbergja_ joined #evergreen |
| 22:34 |
|
cmalm joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:54 |
|
agoben joined #evergreen |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 07:31 |
|
rfrasur joined #evergreen |
| 10:05 |
|
sandbergja joined #evergreen |
| 10:10 |
Dyrcona |
dbs: You want me to add the pullrequest tag to bug 1856047 while I'm confirming and targeting it? |
| 10:10 |
pinesol |
Launchpad bug 1856047 in Evergreen 3.4 "Updating auto_renewal column added in 3.2.0 can take hours or days on large systems" [Low,Confirmed] https://launchpad.net/bugs/1856047 |
| 10:11 |
Dyrcona |
I think someone else will have to test it as I don't have any pre-3.2 database dumps available. |
| 10:30 |
dbs |
Dyrcona: sure sounds good! |
| 10:30 |
Dyrcona |
OK. Done! |
| 10:32 |
Dyrcona |
If anyone disagrees with the Importance I assigned to the bug, feel free to change it. |
| 10:52 |
eby |
are most using the default max stanza size for ejabberd or does it usually require a bump? |
| 10:59 |
berick |
eby: i'm still bumping. there are edge cases |
| 11:01 |
eby |
thanks berick . run into it with some action trigger event creation and wondered if was worth digging into or just happens |
| 11:03 |
Dyrcona |
eby: We bump in production, but I usually leave it alone on test VMs. |
| 11:21 |
|
Christineb joined #evergreen |
| 11:55 |
|
jihpringle joined #evergreen |
| 12:31 |
|
khuckins joined #evergreen |
| 15:19 |
pinesol |
genpaku stole the decoder ring. |
| 15:20 |
eby |
it's definitely the title of the item in the send |
| 15:21 |
eby |
was just curious since I noticed SendEmail has encode_utf8 of the text and uses Mime and handles the same title fine |
| 15:23 |
mmorgan |
miker: It continues. I hadn't intended a virtual index mapping for the title class on my 3.2.9 test system. I removed that and restarted services. That changed the query for my "symphony" title search, but the query results are exactly the same, so that virtual keyword addition was having no effect. Swapping out the english_nostop for simple made a very slight difference in the rel score for two of the records, but not e |
| 15:27 |
JBoyer |
fyi mmorgan, for me that stopped at "two of the records, but not en" in case you wrote much more. |
| 15:27 |
dbs |
oh fun, I guess I forgot that "My List" / "View basket" can't display books that only have a located URI, no physical holdings |
| 15:27 |
mmorgan |
Ok, thanks, here's the rest: |
| 16:25 |
dbs |
doesn't look like it; ebooks are loaded in their own file with just located URIs |
| 16:28 |
dbs |
They're all at CONS; I'll try moving some down to SYS1 and BR1 |
| 16:29 |
dbs |
BOOM |
| 16:31 |
jeff |
cute. |
| 16:31 |
jeff |
yeah, maybe not a very good test data set for located uris to have them all at top of tree. :-) |
| 16:40 |
dbs |
Updated the bug accordingly. Identifying that pattern is 90% of fixing the bug, feels good! |
| 16:42 |
|
rfrasur joined #evergreen |
| 16:42 |
|
jvwoolf1 left #evergreen |
| 16:44 |
|
khuckins joined #evergreen |
| 17:02 |
|
mmorgan left #evergreen |
| 17:24 |
|
sandbergja_ joined #evergreen |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:08 |
|
jihpringle joined #evergreen |
| 18:19 |
jeffdavis |
There is a Perl live test (20-lp1541559-ebook-api.t) which assumes those ebooks have located URIs at CONS, something to watch for if the concerto data is changed |
| 19:09 |
|
cmalm joined #evergreen |
| 19:20 |
dbs |
thanks for the heads-up jeffdavis! |
| 19:38 |
|
sandbergja joined #evergreen |
