| Time |
Nick |
Message |
| 01:34 |
|
sandbergja joined #evergreen |
| 01:58 |
|
sandbergja joined #evergreen |
| 06:44 |
|
jeff_ joined #evergreen |
| 06:49 |
|
RBecker joined #evergreen |
| 06:59 |
|
agoben joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 08:37 |
|
dbwells joined #evergreen |
| 08:44 |
|
mmorgan joined #evergreen |
| 09:04 |
|
yboston joined #evergreen |
| 09:07 |
|
Dyrcona joined #evergreen |
| 09:15 |
|
nfBurton joined #evergreen |
| 09:15 |
|
jvwoolf joined #evergreen |
| 09:33 |
|
nfBurton joined #evergreen |
| 09:55 |
|
rfrasur joined #evergreen |
| 10:00 |
|
mmorgan1 joined #evergreen |
| 10:23 |
|
mmorgan joined #evergreen |
| 10:40 |
|
sandbergja joined #evergreen |
| 10:43 |
|
Christineb joined #evergreen |
| 11:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:23 |
|
yboston joined #evergreen |
| 11:23 |
|
sandbergja joined #evergreen |
| 11:25 |
|
rfrasur joined #evergreen |
| 12:04 |
|
jihpringle joined #evergreen |
| 12:08 |
|
khuckins joined #evergreen |
| 12:34 |
Bmagic |
Christineb: looping waaaay back to the acq import issue. I wanted to ask if Mark was using the Cataloging -> Import/Export Marc Records Angular Interface for this part of the conversation. The issue for us seems to come in when selecting the import type "Acquisitions Records" |
| 12:35 |
|
yboston joined #evergreen |
| 12:36 |
Christineb |
Bmagic - I know he is using the Import/Export Marc Records Angular Interface but I'm not sure he is selecting "Acquisitions Records" I think he just leaves it as Bib records - Mark doesn't work Monday's but I will ask him tomrorow |
| 12:36 |
Bmagic |
no prob |
| 12:37 |
Bmagic |
I believe the bug comes in right there |
| 12:38 |
Bmagic |
once the "Acq records" option is selected - the interface doesn't allow you to choose a record match set |
| 12:38 |
|
alynn26 joined #evergreen |
| 12:48 |
Christineb |
Bmagic - I can confirm - if I choose Acquisitions records I am not able to choose a record match set |
| 12:50 |
Bmagic |
Christineb: ah! Thanks for confirming. I wonder what Mark does |
| 12:50 |
Christineb |
I will check with him tomorrow but I'm pretty certain he just leaves it as Bibliographic records |
| 12:51 |
Bmagic |
If that is the case, then how does Evergreen know to update the acq copy barcodes? |
| 12:56 |
Christineb |
Bmagic - I think that's what the "Auto-overlay In-process Acquisitions Copies" check box is for |
| 12:57 |
Christineb |
or it's this one "Auto-overlay On-order Cataloging Items" |
| 12:57 |
jihpringle |
Mark uses the Auto-overlay On-order Cataloging Items and Use Org Unit Matching in Copy to Determine Best Match check boxes |
| 12:57 |
jihpringle |
custom to us, but I think coming in 3.4 |
| 12:58 |
jihpringle |
I think the files of full records he gets are acq and non-acq libraries combined |
| 13:00 |
jihpringle |
4.3.4 in the release notes - https://evergreen-ils.org/documentation/release/RELEASE_NOTES_3_4.html#_cataloging |
| 13:08 |
|
yboston joined #evergreen |
| 13:23 |
|
yboston joined #evergreen |
| 13:35 |
Christineb |
related bug -> https://bugs.launchpad.net/evergreen/+bug/1849180 |
| 13:35 |
pinesol |
Launchpad bug 1849180 in Evergreen "Inspect Queue for Acquisitions Records does not display" [Undecided,Confirmed] |
| 13:52 |
|
nfBurton joined #evergreen |
| 14:37 |
csharp |
more news on bug 1840950, the error Safari throws when it doesn't load the expire date is "Timepicker directive: "ng-model" value must be a Date object, a number of milliseconds since 01.01.1970 or a string representing an RFC2822 or ISO 8601 date." |
| 14:37 |
pinesol |
Launchpad bug 1840950 in Evergreen "Patron expiration date & iPads" [Medium,Confirmed] https://launchpad.net/bugs/1840950 |
| 14:38 |
csharp |
so I'm wondering why Safari would be more strict than Chrome/FF about that? |
| 14:38 |
|
sandbergja joined #evergreen |
| 14:40 |
csharp |
also, going to look into adding console output statements to find out what it's actually seeing get returned |
| 14:44 |
csharp |
and why date of birth is not causing the same error. |
| 14:46 |
csharp |
on that last, in the test account I'm playing with, dob has the date in YYYY-MM-DD and expire date is YYYY-MM-DD HH:mm:ss-<offset> |
| 14:48 |
jeff |
that console error is from an old version of UI Bootstrap. it's not present in the current (archived, read-only) code. |
| 14:48 |
jeff |
(this info isn't directly helpful, sorry) |
| 14:50 |
jeff |
the error text was changed in this commit: https://github.com/angular-ui/bootstrap/commit/aa010b024e936b9ced66a58726d4fe591be9383c |
| 14:51 |
csharp |
hmm - interesting |
| 14:51 |
jeff |
https://github.com/angular-ui/bootstrap/issues/5191 then references the myriad reasons why they opted to stop supporting things like strings as input. |
| 14:52 |
jeff |
anyway, my first theory was "because safari implements more of the HTML5 date input type than most other browsers", but might be unrelated to any of that. |
| 14:53 |
csharp |
ok, so seems to me from my mostly uninformed view that the Right Thing™ to do would be to tranform the date into a JS date object? |
| 14:53 |
csharp |
tranform the timestamp, rather |
| 14:54 |
csharp |
(knowing that we will be moving this UI to Angular in time) |
| 14:56 |
Dyrcona |
jeff: https://www.w3schools.com/TAGS/att_input_type_date.asp says Safari doesn't support input type date.... |
| 14:57 |
Dyrcona |
And, yeah, it may not be all that relevant... |
| 15:01 |
jeff |
Dyrcona: sorry, should have been more specific: Safari on iOS |
| 15:02 |
Dyrcona |
Well, yeah, I was originally gonna say that it does seem to support it on iOS, but not Mac OS X, which seems completely backwards, but Apple..... |
| 15:02 |
jeff |
but yes, i'm less supportive of my earlier theory than i was before. :-) |
| 15:02 |
|
rfrasur joined #evergreen |
| 15:03 |
jeff |
I think Safari on iOS got lots of things before desktop Safari, or that desktop Safari never received. My impression was that much of it was in the interest of eliminating keyboard frustration for iOS device users. |
| 15:04 |
Dyrcona |
Sounds plausible. |
| 15:13 |
|
jvwoolf joined #evergreen |
| 15:15 |
csharp |
I should clarify that right now I'm working on Safari on MacOS |
| 15:16 |
csharp |
since iOS Safari doesn't have built-in debugging tools and I'm seeing the issue manifest on the MacOS version |
| 15:17 |
csharp |
so my approach is based on the hope that if I fix it on MacOS, it will also work on iOS, which may be a foolish assumption |
| 15:19 |
Dyrcona |
:) |
| 15:39 |
jonadab |
I would say it is probably worth trying. |
| 15:39 |
jonadab |
Because, you never know, it _might_ work. |
| 15:40 |
jonadab |
And it's almost certainly easier to fix the bug _with_ debugging tools, than without. |
| 15:57 |
jeffdavis |
In a multi-server setup, should the hosts block at the end of opensrf.xml refer to all the different EG servers in your environment? |
| 15:59 |
|
khuckins joined #evergreen |
| 15:59 |
csharp |
jeffdavis: it should refer to at least the machine it's on - adding other machines there so you can manage a single file across servers is fine, but not required |
| 16:00 |
csharp |
e.g., we have all the brick/sip/reporter/utility configs in the single file that gets copied everywhere |
| 16:04 |
jeffdavis |
We're listing our all application and utility servers which I think means requests may be routed to any of those. Since we have a load balancer sitting in front of those servers I wonder if it's better just to let the LB handle routing and let each server itself. |
| 16:05 |
jeffdavis |
*let each server fend for itself |
| 16:08 |
berick |
jeffdavis: simply adding a host to opensrf.xml does not mean requests will be routed to it. |
| 16:12 |
berick |
there are ways to make that happen, but requires more setup |
| 16:13 |
jeffdavis |
Absent additional setup, is there a reason to add other servers there besides the current one? |
| 16:15 |
berick |
jeffdavis: yeah, csharp 's scenario is one |
| 16:15 |
berick |
we have 1 "brick" opensrf.xml and one "sip" opensrf.xml, etc. |
| 16:16 |
berick |
it's just fewer files to maintine |
| 16:16 |
berick |
*maintain |
| 16:18 |
berick |
but if Host A gets a request, the fact that Host B is also in its opensrf.xml file is irrelevant |
| 16:21 |
jeffdavis |
OK, I see. Thank you! |
| 16:25 |
sandbergja |
Is anybody batch loading patron records from systems that have preferred names? If so, do you map the other system's preferred name to Evergreen's preferred name? Or throw the legal name into name keywords? Or just forget about one of the names from the other system? |
| 16:28 |
|
jvwoolf left #evergreen |
| 16:35 |
jihpringle |
sandbergja: we're just starting to work with our academics to map preferred name into Evergreen (since upgrading to 3.3 last month) |
| 16:37 |
sandbergja |
jihpringle: oh! Good to know! We're still back on 3.1, so we don't have preferred name in Evergreen yet, so we're trying to think of a strategy |
| 16:37 |
jihpringle |
we told our libraries they had to wait for 3.3 |
| 16:39 |
sandbergja |
One question I've had locally: do we need to store both the preferred name and the legal name? Do we really need the legal name for any of our Evergreen work? Do you have a sense for why your academics would like both preferred and legal names in Evergreen? |
| 16:40 |
jihpringle |
those questions haven't really come up for us yet |
| 16:40 |
jihpringle |
we're at the stage of getting test records with preferred name included from a couple of our academics |
| 16:41 |
jihpringle |
for those we're expecting to load both legal and preferred name |
| 16:42 |
sandbergja |
Good luck with that process! Thanks for your help -- okay if I pick your brain after you are farther into that process? |
| 16:42 |
jihpringle |
thanks and absolutely |
| 16:43 |
jihpringle |
it might also be a good question for the next student success group meeting |
| 16:44 |
jihpringle |
sandbergja ^^ |
| 16:47 |
sandbergja |
hahaha very true |
| 16:47 |
sandbergja |
That means I have to schedule the next student success working group meeting :-) |
| 16:47 |
jihpringle |
I vote for January (over December) :) |
| 16:57 |
|
khuckins joined #evergreen |
| 17:01 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live/test.7.html#2019-11-25T16:45:39,681718863-0500 -0> |
| 17:01 |
pinesol |
News from qatests: Failed Building OpenSRF <http://testing.evergreen-ils.org/~live/test.9.html#2019-11-25T16:45:39,708141366-0500 -2> |
| 17:01 |
pinesol |
News from qatests: Failed Running OpenSRF build tests <http://testing.evergreen-ils.org/~live/test.10.html#2019-11-25T16:45:39,734605538-0500 -4> |
| 17:01 |
pinesol |
News from qatests: Failed Installing OpenSRF <http://testing.evergreen-ils.org/~live/test.11.html#2019-11-25T16:45:39,761288829-0500 -6> |
| 17:01 |
pinesol |
News from qatests: Failed updating /etc/hosts <http://testing.evergreen-ils.org/~live/test.13.html#2019-11-25T16:45:39,787742381-0500 -8> |
| 17:01 |
pinesol |
News from qatests: Failed configuring ejabberd <http://testing.evergreen-ils.org/~live/test.15.html#2019-11-25T16:45:39,814375373-0500 -10> |
| 17:01 |
pinesol |
News from qatests: Failed creating jabber users <http://testing.evergreen-ils.org/~live/test.16.html#2019-11-25T16:45:39,840791114-0500 -12> |
| 17:01 |
pinesol |
News from qatests: Failed configuring OpenSRF <http://testing.evergreen-ils.org/~live/test.17.html#2019-11-25T16:45:39,867311142-0500 -14> |
| 17:01 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.18.html#2019-11-25T16:45:39,894126627-0500 -16> |
| 17:01 |
pinesol |
News from qatests: Failed stop opensrf <http://testing.evergreen-ils.org/~live/test.19.html#2019-11-25T16:45:39,920558926-0500 -18> |
| 17:01 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.20.html#2019-11-25T16:45:39,946936529-0500 -20> |
| 17:01 |
pinesol |
News from qatests: Failed test opensrf <http://testing.evergreen-ils.org/~live/test.21.html#2019-11-25T16:45:39,973464938-0500 -22> |
| 17:01 |
pinesol |
News from qatests: Failed configuring websockets <http://testing.evergreen-ils.org/~live/test.22.html#2019-11-25T16:45:39,999807878-0500 -24> |
| 17:01 |
pinesol |
News from qatests: Failed stop opensrf <http://testing.evergreen-ils.org/~live/test.23.html#2019-11-25T16:45:40,026329460-0500 -26> |
| 17:01 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live/test.29.html#2019-11-25T16:45:40,052962379-0500 -28> |
| 17:01 |
pinesol |
News from qatests: Failed Building Evergreen <http://testing.evergreen-ils.org/~live/test.30.html#2019-11-25T16:45:40,079548880-0500 -30> |
| 17:01 |
pinesol |
News from qatests: Failed Running Evergreen tests <http://testing.evergreen-ils.org/~live/test.31.html#2019-11-25T16:45:40,106020375-0500 -32> |
| 17:01 |
pinesol |
News from qatests: Failed Installing Evergreen <http://testing.evergreen-ils.org/~live/test.32.html#2019-11-25T16:45:40,132437083-0500 -34> |
| 17:01 |
pinesol |
News from qatests: Failed Change File Ownership <http://testing.evergreen-ils.org/~live/test.33.html#2019-11-25T16:45:40,159147985-0500 -36> |
| 17:01 |
pinesol |
News from qatests: Failed Installing Dojo <http://testing.evergreen-ils.org/~live/test.35.html#2019-11-25T16:45:40,185657503-0500 -38> |
| 17:01 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live/test.36.html#2019-11-25T16:45:40,212067284-0500 -40> |
| 17:01 |
pinesol |
News from qatests: Failed configure EG OpenSRF <http://testing.evergreen-ils.org/~live/test.37.html#2019-11-25T16:45:40,238680534-0500 -42> |
| 17:01 |
pinesol |
News from qatests: Failed configure EG Action/Trigger <http://testing.evergreen-ils.org/~live/test.38.html#2019-11-25T16:45:40,265090706-0500 -44> |
| 17:01 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live/test.41.html#2019-11-25T16:45:40,291499810-0500 -46> |
| 17:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-11-25T16:45:40,318294201-0500 -48> |
| 17:01 |
pinesol |
News from qatests: Failed start opensrf <http://testing.evergreen-ils.org/~live/test.43.html#2019-11-25T16:45:40,344670818-0500 -50> |
| 17:01 |
|
jonadab joined #evergreen |
| 17:01 |
pinesol |
News from qatests: Failed Running autogen.sh <http://testing.evergreen-ils.org/~live/test.44.html#2019-11-25T16:45:40,371369598-0500 -52> |
| 17:01 |
pinesol |
News from qatests: Failed Restarting Apache <http://testing.evergreen-ils.org/~live/test.45.html#2019-11-25T16:45:40,397989205-0500 -54> |
| 17:01 |
pinesol |
News from qatests: Failed test EG opensrf <http://testing.evergreen-ils.org/~live/test.46.html#2019-11-25T16:45:40,424422216-0500 -56> |
| 17:01 |
pinesol |
News from qatests: Failed Running pgTAP live tests <http://testing.evergreen-ils.org/~live/test.47.html#2019-11-25T16:45:40,451206084-0500 -58> |
| 17:01 |
pinesol |
News from qatests: Failed Running settings-tester.pl <http://testing.evergreen-ils.org/~live/test.48.html#2019-11-25T16:45:40,477946058-0500 -60> |
| 17:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.49.html#2019-11-25T16:45:40,504622784-0500 -62> |
| 17:01 |
pinesol |
News from qatests: Failed Gathering log summary <http://testing.evergreen-ils.org/~live/test.50.html#2019-11-25T16:45:40,532204661-0500 -64> |
| 17:01 |
pinesol |
News from qatests: Failed Log Output: config.log <http://testing.evergreen-ils.org/~live/test.51.html#2019-11-25T16:45:40,559102863-0500 -66> |
| 17:02 |
berick |
heh, looks like an Angular exception stack trace |
| 17:17 |
|
mmorgan left #evergreen |
| 18:36 |
|
jihpringle joined #evergreen |
| 19:03 |
|
cmalm_ joined #evergreen |
| 22:37 |
|
sandbergja joined #evergreen |
| 23:39 |
|
cmalm joined #evergreen |
