| 02:29 |
|
cmalm joined #evergreen |
| 03:09 |
|
kip joined #evergreen |
| 05:54 |
|
dbwells_ joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:54 |
|
rfrasur joined #evergreen |
| 07:02 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 10:37 |
|
sandbergja__ joined #evergreen |
| 10:57 |
gmcharlt |
csharp: I've updated 1811710 |
| 11:04 |
csharp |
gmcharlt: responded |
| 11:05 |
gmcharlt |
csharp: thanks |
| 11:05 |
gmcharlt |
two more questions |
| 11:06 |
gmcharlt |
1. is the test DB in question still around? if so, I'd like to see the result of select * from pg_attribute where attname = 'hopeless_date'; |
| 11:06 |
gmcharlt |
2. is it possible that the test DB would have originated from a database that was created back in the pre-Pg-8.3 days? |
| 11:07 |
gmcharlt |
in particular, of a lineage that would have be upgraded via pg_upgrade, not pg_dump & restore? |
| 11:07 |
csharp |
1. the DB is around, but I dropped the hopeless columns to fully roll back the changes |
| 11:08 |
csharp |
2. I've used pg_upgrade to go from 9.3 -> 9.5, then 9.5 -> 9.6, but it was all pg_dump/pg_restore before that |
| 11:09 |
gmcharlt |
ok, in that DB, what attypid values do you get from select * from pg_attribute where attname = 'request_time';? |
| 15:54 |
Dyrcona |
And, with that, I'm signing out for the day. |
| 16:00 |
jeffdavis |
the fix for bug 1848550 will mitigate open-ils.actor drone exhaustion |
| 16:00 |
pinesol |
Launchpad bug 1848550 in Evergreen "Cache settings more aggressively in web client" [Undecided,Confirmed] https://launchpad.net/bugs/1848550 |
| 16:01 |
jeffdavis |
I still need to test the Angular parts on that one |
| 16:05 |
|
rfrasur joined #evergreen |
| 16:18 |
|
mmorgan joined #evergreen |
| 16:23 |
dbs |
jeffdavis++ |
| 17:03 |
|
mmorgan left #evergreen |
| 17:34 |
|
jihpringle joined #evergreen |
| 17:35 |
|
rfrasur joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:20 |
|
sandbergja_ joined #evergreen |
| 19:26 |
|
sandbergja_ joined #evergreen |
| 01:13 |
|
cmalm joined #evergreen |
| 01:27 |
|
cmalm joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:55 |
|
agoben joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:17 |
|
collum joined #evergreen |
| 14:25 |
|
Jeff_ARE joined #evergreen |
| 14:27 |
Jeff_ARE |
I'm struggling to import MARC records into a new (my first) Evergreen install. When I upload a file with a single record the Upload Progress quickly goes to 100%, but the Enqueue Progress never moves beyond 0%. The Inspect Queue tab shows show the import in the queue but it never finishes. Do I need to do anything to kickstart the processing of the |
| 14:27 |
Jeff_ARE |
queue? This is my first Evergreen experience so I may be missing something |
| 14:28 |
rfrasur |
Jeff_ARE, are you import using the batch importer with only one record because of testing? |
| 14:28 |
rfrasur |
s/import/importing |
| 14:29 |
Jeff_ARE |
Yes. I tried 5000 records and same result, then tried 100 records and same result. So for testing am just trying a single record |
| 14:29 |
berick |
Jeff_ARE: beware of https://bugs.launchpad.net/evergreen/+bug/1855199 |
| 14:29 |
rfrasur |
Gotcha. Hold on real quick. |
| 14:29 |
pinesol |
Launchpad bug 1855199 in Evergreen "Vandelay record queuing can fail if spool directory is /tmp" [Medium,Confirmed] |
| 17:29 |
|
_bott_ joined #evergreen |
| 17:37 |
|
_bott_ joined #evergreen |
| 17:52 |
|
_bott_ joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:03 |
|
_bott_ joined #evergreen |
| 18:48 |
|
_bott_ joined #evergreen |
| 19:08 |
|
_bott_ joined #evergreen |
| 02:18 |
|
cmalm joined #evergreen |
| 02:29 |
|
cmalm_ joined #evergreen |
| 02:43 |
|
cmalm joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:43 |
|
_bott_ joined #evergreen |
| 06:57 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 11:02 |
dbs |
We had two separate instances of clark-kent.pl running, each with --concurrency 2 |
| 11:30 |
|
sandbergja joined #evergreen |
| 11:49 |
|
_bott_ joined #evergreen |
| 11:59 |
gmcharlt |
csharp: re 1811710, do you happen to still have final fm_IDL.xml as installed on your test system? |
| 12:02 |
|
jihpringle joined #evergreen |
| 12:05 |
jeff |
Thinking about the physical logistics of distributing a large number of new patron cards (>5000): has anyone here ordered cards from somewhere where they're pre-stuck to a card / mailer, or something creative like that? |
| 12:05 |
jeff |
or used a removable sticker on the card? |
| 14:00 |
csharp |
gmcharlt: https://pastebin.com/a263dZ74 |
| 14:12 |
jeffdavis |
autogen? |
| 14:13 |
|
Christineb joined #evergreen |
| 14:14 |
csharp |
jeffdavis: I ran autogen - no dice |
| 14:15 |
csharp |
after we upgrade this weekend, we'll put it back on our test server so we can suss it out non-forensically |
| 14:48 |
|
_bott_1 joined #evergreen |
| 15:04 |
jihpringle |
sandbergja: is LP 1852782 the best bug to add the screenshot to? |
| 15:04 |
pinesol |
Launchpad bug 1852782 in Evergreen "Angular MARC Editor Part 2 -- Enriched Editor" [Wishlist,New] https://launchpad.net/bugs/1852782 |
| 16:28 |
|
sandbergja_ joined #evergreen |
| 17:12 |
|
mmorgan left #evergreen |
| 17:32 |
|
stephengwills left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:47 |
|
stephengwills joined #evergreen |
| 20:48 |
|
stephengwills left #evergreen |
| 20:54 |
|
sandbergja joined #evergreen |
| 00:37 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:07 |
|
rfrasur joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:49 |
|
collum joined #evergreen |
| 14:21 |
|
_bott_ joined #evergreen |
| 14:35 |
|
_bott_ joined #evergreen |
| 14:40 |
|
_bott_ joined #evergreen |
| 14:48 |
csharp |
seeing some log errors on our test server that don't make sense to me: 2020-01-13 14:38:44 next-brick01-head open-ils.cstore: [ERR :20970:oils_sql.c:6993:1578914702188581199] open-ils.cstore ERROR No "datatype" attribute for field "hopeless_prone" |
| 14:48 |
csharp |
we've applied the hopeless holds branch and are planning to go live with it |
| 14:49 |
csharp |
fm_IDL.xml hwas this: <field name="hopeless_prone" reporter:datatype="bool"/> |
| 14:49 |
csharp |
so I don't know what the code is looking for if not that |
| 14:50 |
mmorgan |
csharp: I believe hopeless_prone would be an attribute of a copy status |
| 14:50 |
csharp |
right |
| 14:50 |
* Dyrcona |
sighs. |
| 17:23 |
|
_bott_ joined #evergreen |
| 17:38 |
|
khuckins joined #evergreen |
| 17:49 |
|
sandbergja_ joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:06 |
|
stephengwills left #evergreen |
| 18:15 |
|
sandbergja_ joined #evergreen |
| 19:25 |
|
sandbergja_ joined #evergreen |
| 01:23 |
|
cmalm joined #evergreen |
| 01:53 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live//archive/2020-01/2020-01-10_04:00:02/test.41.html> |
| 06:57 |
|
rfrasur joined #evergreen |
| 07:26 |
|
rjackson_isl joined #evergreen |
| 08:28 |
pastebot |
"phasefx" at 168.25.130.30 pasted "re: pgtap failure" (34 lines) at http://paste.evergreen-ils.org/10119 |
| 08:31 |
csharp |
investigating an issue where bib TCNs are getting changed to the record ID upon saving - I've ruled out BibCommon.pm as a possible cause - now looking at marcedit.js |
| 08:32 |
csharp |
apparently only happening when editing an existing record - imports from z39.50 are not affected as far as I understand |
| 08:32 |
csharp |
confirmed - only already existing records |
| 08:32 |
|
Dyrcona joined #evergreen |
| 08:33 |
csharp |
(on 3.4 testing server, btw) |
| 08:35 |
|
sandbergja joined #evergreen |
| 08:40 |
|
mantis1 joined #evergreen |
| 08:44 |
|
_bott_ left #evergreen |
| 10:54 |
gmcharlt |
upshot: open-ils.cat.biblio.record.xml.update appears to be what's needed |
| 10:55 |
gmcharlt |
also, this affects both the AngularJS and Angular sides |
| 10:57 |
* berick |
follows conversation |
| 10:58 |
csharp |
gmcharlt++ |
| 11:04 |
csharp |
gmcharlt: I can confirm that changing that call to xml.update works |
| 11:53 |
|
mmorgan joined #evergreen |
| 11:57 |
|
jihpringle joined #evergreen |
| 11:57 |
csharp |
gmcharlt: I added a branch to bug 1859191 for review - not sure about how to test Angular cataloging |
| 11:57 |
pinesol |
Launchpad bug 1859191 in Evergreen "Editing and saving MARC record changes the TCN value" [High,Confirmed] https://launchpad.net/bugs/1859191 |
| 12:10 |
|
rfrasur joined #evergreen |
| 12:12 |
|
yboston joined #evergreen |
| 12:19 |
|
aabbee left #evergreen |
| 16:34 |
|
dbwells joined #evergreen |
| 16:46 |
|
jvwoolf left #evergreen |
| 17:04 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:14 |
|
dbwells_ joined #evergreen |
| 18:37 |
|
_bott_ joined #evergreen |
| 21:18 |
|
sandbergja joined #evergreen |
| 02:26 |
|
cmalm joined #evergreen |
| 02:50 |
|
cmalm joined #evergreen |
| 03:11 |
|
cmalm joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 08:16 |
|
alynn26 joined #evergreen |
| 14:09 |
abneiman |
probably so. +1 to collab alynn26 |
| 14:10 |
dluch |
That would be great. And maybe we could do some version as an online thing for folks who can't be at conference |
| 14:10 |
abneiman |
dluch: that's a good idea |
| 14:10 |
dluch |
abneiman++ alynn26++ |
| 14:11 |
dluch |
#3, abneiman: I know you have prodded gmcharlt about the test server. More on that shortly, unless you want to say anything now? |
| 14:11 |
abneiman |
nope nothing from me |
| 14:11 |
dluch |
abneiman++ |
| 14:11 |
dluch |
#4, sandbergja, gmcharlt, and/or Dyrcona: how's work on setting up a git repo for ui (and maybe layouts) coming? |
| 14:15 |
Bmagic |
tkatie217: Thank you :) |
| 14:15 |
dluch |
remingtron++ |
| 14:15 |
Bmagic |
remingtron++ |
| 14:16 |
dluch |
#6, Everyone will test the new Antora server and email the DIG list (or IRC) with problems (or suggestions). I don't think I've seen many (any?) emails with problems or suggestions. How is testing going? (Also, more on Antora shortly.) |
| 14:17 |
dluch |
crickets... |
| 14:17 |
alynn26 |
It looks great. |
| 14:17 |
Bmagic |
:) |
| 14:17 |
dluch |
I agree, it does look great |
| 14:17 |
remingtron |
there are still little bugs hiding everywhere, so please test! |
| 14:18 |
dluch |
I'll keep that on as an action item, then. :-) |
| 14:18 |
Bmagic |
yep - lots of hidden "gems" in there |
| 14:18 |
dluch |
#action Everyone will test the Antora server and email the DIG list (or IRC) with problems (or suggestions). |
| 14:18 |
alynn26 |
Home icon needs updating. If you click on it it goes to the "it's powered by Antora". |
| 14:19 |
remingtron |
alynn26++ #testing! |
| 14:19 |
Bmagic |
lol |
| 14:19 |
Bmagic |
I threw that page on there in the very very beginning |
| 14:19 |
dluch |
Good find, lol |
| 14:22 |
tkatie217 |
+remingtron that would make sense :) |
| 14:22 |
alynn26 |
I think it does, if you check out the Glossary it says Glossary. |
| 14:23 |
sandbergja |
alynn26: I think the glossary looks so cool in antora. :-) |
| 14:23 |
dluch |
navlabels++ :-D |
| 14:23 |
dluch |
Okay, everyone keep up the good testing! Let's move on |
| 14:23 |
tkatie217 |
+1 to glossary! gorgeous! |
| 14:24 |
dluch |
+1 The glossary really is awesome |
| 14:24 |
dluch |
#info Update on Documentation server move |
| 14:24 |
alynn26 |
I do have an update to the Glossary, With a few additional features. Here is my testing Gist: https://gist.github.com/alynn26/072bcda581fead021eab2f079dd49e82 |
| 14:24 |
dluch |
It doesn't look like rsoulliere is here right now...how's this going? |
| 14:25 |
dluch |
gmcharlt: how's this going? |
| 14:25 |
dluch |
alynn26++ |
| 17:07 |
|
mmorgan joined #evergreen |
| 17:09 |
|
jihpringle joined #evergreen |
| 17:12 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:13 |
|
stephengwills left #evergreen |
| 18:24 |
|
khuckins joined #evergreen |
| 20:18 |
|
sandbergja joined #evergreen |
| 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 |
