| Time |
Nick |
Message |
| 00:23 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:00 |
|
agoben joined #evergreen |
| 07:09 |
|
rfrasur joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:15 |
|
Dyrcona joined #evergreen |
| 08:13 |
|
collum joined #evergreen |
| 08:26 |
|
mantis1 joined #evergreen |
| 08:47 |
|
mmorgan joined #evergreen |
| 08:47 |
|
Dyrcona joined #evergreen |
| 09:39 |
|
sandbergja joined #evergreen |
| 09:42 |
|
yboston joined #evergreen |
| 09:54 |
|
jvwoolf joined #evergreen |
| 09:57 |
|
cmalm joined #evergreen |
| 10:24 |
|
alynn26 joined #evergreen |
| 10:24 |
|
alynn26_away joined #evergreen |
| 10:25 |
|
alynn26 joined #evergreen |
| 10:32 |
dbs |
Weird. Some of our staff got new workstations, so they tried setting up Chrome + Hatch and get whitescreens of death as soon as Hatch is enabled. I can't see any error messages in the console. |
| 10:33 |
dbs |
Chrome extensions say it's Hatch 0.2.2, FWIW, even though Hatch was downloaded and installed through evergreen-ils.org/downloads |
| 10:34 |
dbs |
I did get them up and running with Firefox + Hatch 0.3.2, but the Chrome issue is puzzling |
| 10:39 |
jeff |
My understanding is that the Hatch installer just tells Chrome to install the Hatch extension from the Chrome Web Store. The latest version there is 0.2.2 from my POV. |
| 11:06 |
dbs |
jeff: so it seems. I think I recall berick saying that the version of the Hatch extension didn't matter but perhaps that was related to something else. |
| 11:09 |
dbs |
(it is confusing / potentially a red herring to see a mismatch between the version listed at evergreen-ils.org/downloads and the Chrome Web Store, though) |
| 11:18 |
jeff |
yeah, describing the download as "Web Staff Client Extension" might be adding to that confusion. |
| 11:19 |
jeff |
the native messaging host and the browser extension are two independent things with independent version strings, with the browser extension being intended to be backward compatible. |
| 11:19 |
jeff |
so the latest version of the extension should always be automatically in place from the respective browser store/repository |
| 11:36 |
|
sandbergja joined #evergreen |
| 12:04 |
|
jihpringle joined #evergreen |
| 12:10 |
JBoyer |
jeff, dbs, the version of hatch *usually* doesn't matter, but sometimes things like bug 1857729 hit and suddenly it matters very much. |
| 12:10 |
pinesol |
Launchpad bug 1857729 in Evergreen "Hatch does not load in Angular Client in Firefox" [Undecided,Fix released] https://launchpad.net/bugs/1857729 |
| 12:11 |
JBoyer |
That can't be the exact case on chrome, but I wonder if it's something similarly hidden until you run the right combination of versoins. |
| 12:23 |
dbs |
re: that bug: I could occasionally get the workstation registration page to come up on Chrome with Hatch 0.2.2. I dunno, it's weird, it worked with their old workstations. |
| 12:26 |
|
khuckins joined #evergreen |
| 12:29 |
berick |
the version in the chrome store is def. the one you want, regardless of the version # mismatch |
| 12:29 |
berick |
(which i agree is confusing) |
| 12:33 |
|
collum joined #evergreen |
| 12:50 |
|
rfrasur joined #evergreen |
| 12:58 |
JBoyer |
dbs, if you enable developer mode on the extensions page in chrome and then look at hatch, it should give you the option to inspect the background page. that's where some of the more interesting extension logging is done. |
| 12:59 |
JBoyer |
I couldn't tell if you were in there or not above, since they're both "consoles" :) |
| 13:30 |
|
rfrasur joined #evergreen |
| 13:33 |
|
JeffG_ARE joined #evergreen |
| 13:37 |
JeffG_ARE |
I've been unsuccessful getting a batch import to work, wondering if I can get some help? After I upload a MARC file it shows, for example: "Records in Queue: 200; Records imported: 200; Records Import Failures: 0; Items in Queue: 200; Items Imported: 0; Item Import Failures: 0." Then when I click "Import All Records" and try to import them, when I |
| 13:37 |
JeffG_ARE |
click the Upload button it just shows the progress bar stuck at 0%. Firefox gives the console error 'ERROR TypeError: "this.selectedQueue is undefined"' and Chrome gives the console error "ERROR TypeError: Cannot read property 'freetext' of undefined" |
| 13:38 |
JeffG_ARE |
Any ideas? |
| 13:48 |
mantis1 |
For anyone who edits column pickers in the web client; sometimes when it comes to adding columns it's hit or miss. Sometimes I put in the path for the element that I figure out in PGAdmin, and other times, I can't figure out what it is. |
| 13:48 |
mantis1 |
Does anyone use a sure fire process that helps? |
| 13:55 |
jeff |
JeffG_ARE: first thing that comes to mind is to ensure that your uploaded MARC data isn't being put somewhere like /tmp, which can be problematic with systemd's PrivateTmp feature. |
| 13:56 |
JeffG_ARE |
Thanks. I had that problem before and this group helped me solve the problem. Data is being uploaded to /openils/var/tmp |
| 13:56 |
jeff |
JeffG_ARE: ah, good. that's one thing you can cross off. |
| 14:03 |
remingtron |
JeffG_ARE: I think the normal process is to import both records and items (holdings) at the same time. You might be doing things in an order that Evergreen didn't expect. |
| 14:04 |
remingtron |
Try setting a "Holdings Import Profile" as part of the first step. |
| 14:04 |
JeffG_ARE |
Thanks. I'm not sure what's going on then. I have the holding info in the MARC files, I've specified the 852 export format as the Holdings Import Profile, but it doesn't seem to import |
| 14:05 |
JeffG_ARE |
If I click through to see one of the imported items, all the biblio info is there, but no holdings are created. If I view the MARC info for the item is shows all the 852 data that I expect |
| 14:06 |
JeffG_ARE |
Example here: http://paste.evergreen-ils.org/10126 |
| 14:14 |
rjackson_isl |
Doe is matter that there are two 852 $b entries? |
| 14:14 |
rjackson_isl |
s/Doe/Does |
| 14:16 |
JeffG_ARE |
I don't know. The 852 specification says: "Owning Library: [@code = "b"][1] ; and Circulating Library: [@code = "b"][2]" which I assumed meant first and second entry |
| 14:18 |
rjackson_isl |
probably not - used to using the migration utilities where it does matter about duplicates - not a lot of experience using the online import |
| 14:21 |
JeffG_ARE |
OK, I'll try a different import format that doesn't have the duplicates issue |
| 14:22 |
rjackson_isl |
I would hold off for a second opinion JeffG_ARE |
| 14:23 |
rjackson_isl |
just looked at our Hodlings Import Profiles and we do have one set up with Owning Library and Circulating Library coming from the 852 b [@code="b"][1] and [2] |
| 14:54 |
|
khuckins joined #evergreen |
| 15:21 |
mmorgan |
mantis1: Are you talking about adding columns that aren't there to the list of available ones? If so you need to follow the paths in the fm_IDL, which sometimes are the same as the database tables, and sometimes not. |
| 15:26 |
|
mantis1 left #evergreen |
| 15:43 |
|
mmorgan1 joined #evergreen |
| 15:50 |
|
khuckins joined #evergreen |
| 15:56 |
JeffG_ARE |
@rjackson_isl: I tried a modified 999 format to eliminate the duplicates and the results are the same - import goes OK without errors but no holdings are created |
| 15:56 |
pinesol |
JeffG_ARE: You keep using that word. I do not think it means what you think it means. |
| 15:56 |
JeffG_ARE |
Which word? |
| 15:56 |
berick |
JeffG_ARE: you don't need the '@' |
| 15:56 |
berick |
that awakens the bot |
| 15:57 |
JeffG_ARE |
OK |
| 15:58 |
JeffG_ARE |
So my reading of the documentation is that the import process it two steps - 1 to import the records and 2 to import the holdings (http://docs.evergreen-ils.org/3.2/_import_records.html). For some reason with the 999 format it doesn't error out as before but it still does not create the holdings |
| 15:59 |
JeffG_ARE |
I am selecting "Import Non-Matching Records" when I do the import as these are all new records |
| 16:14 |
|
mmorgan joined #evergreen |
| 16:17 |
jihpringle |
JeffG_ARE: If you haven't already, you'll want to compare the holdings information in your MARC records and the Holdings Import Profile you're using |
| 16:18 |
JeffG_ARE |
Thank you. Yes, it all matches. After the import when I view the queue and click "View Import Items" that all looks good as well |
| 16:20 |
JeffG_ARE |
Is there any other way to import holdings? Because at this point we're looking at having to add ~23,000 items manually :-/ |
| 16:23 |
Dyrcona |
Well, you can always load asset.copy records and asset.call_number records via SQL. |
| 16:25 |
JeffG_ARE |
Call numbers... would lack of call numbers cause the holdings imports to fail? Our library doesn't make use of call numbers |
| 16:25 |
alynn26 |
JeffG_ARE, i was looking at the one you gave us, the one thing I am seeing missing is a call number in the 852. Unless that is what you have $g for. |
| 16:26 |
Dyrcona |
alynn26++ |
| 16:26 |
JeffG_ARE |
alynn26: our library doesn't use call numbers... is that a required field? |
| 16:26 |
alynn26 |
yep |
| 16:26 |
JeffG_ARE |
Well that's a bummer. haha |
| 16:27 |
Dyrcona |
JeffG_ARE: It's how Evergreen finds copies from a bibliographic record. |
| 16:27 |
alynn26 |
It can be anything. It's in hierarchy of the database. |
| 16:27 |
Dyrcona |
biblio.record_entry.id -> asset.call_number.record asset.call_number.id -> asset.copy.call_number |
| 16:32 |
Dyrcona |
oops. Guess that's a deal breaker. |
| 16:33 |
alynn26 |
yep |
| 16:41 |
|
JeffG_ARE joined #evergreen |
| 16:42 |
JeffG_ARE |
I got disconnect, but THANK YOU everyone, the imports are working now. Missing call numbers was the culprit |
| 16:42 |
alynn26 |
you are welcome |
| 17:00 |
|
jihpringle joined #evergreen |
| 17:01 |
|
jvwoolf left #evergreen |
| 17:04 |
|
mmorgan left #evergreen |
| 17:26 |
jeffdavis |
Is anyone syncing autogen results across multiple servers? Do you have a script you use for that? |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:27 |
|
cmalm joined #evergreen |
| 20:37 |
|
sandbergja joined #evergreen |
| 22:46 |
|
sandbergja joined #evergreen |
