| Time |
Nick |
Message |
| 00:37 |
|
jweston joined #evergreen |
| 01:00 |
|
eby joined #evergreen |
| 07:34 |
|
rfrasur joined #evergreen |
| 07:39 |
|
kworstell-isl joined #evergreen |
| 08:05 |
|
BDorsey joined #evergreen |
| 08:46 |
|
mmorgan joined #evergreen |
| 09:02 |
|
dguarrac joined #evergreen |
| 09:33 |
Bmagic |
does anyone have an EDI vendor where the FTP folder name has a dash? like "drop-off" ? |
| 09:33 |
Bmagic |
I'm wondering if that trips our code for filename generation around line 267 in RemoteAccount.pm |
| 09:46 |
|
BDorsey joined #evergreen |
| 09:51 |
|
kworstell_isl joined #evergreen |
| 09:51 |
|
kworstell_isl_ joined #evergreen |
| 10:11 |
pinesol |
News from commits: LP2035383: Add docs/package.json to .gitignore <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=7b11cffa8db69eb0d5f214df2f632a0473d1d4bd> |
| 10:36 |
Bmagic |
does anyone here know why edi_order_pusher uses the "account" field to login to the FTP account? When I make it null, the code logs in successfully. When I set the account field to be correct, it fails to login to the remote FTP server |
| 10:40 |
Bmagic |
looking at Net::FTP login([$login[, $password[, $account]]]) |
| 10:41 |
Bmagic |
I don't think I understand the third parameter "account" |
| 10:45 |
jeff |
The FTP protocol has a concept of an "account" after the initial login/username and password. It is infrequently used, but logical that Net::FTP supports it. |
| 10:45 |
jeff |
s/after/in combination with/ might be more accurate. |
| 10:46 |
jeff |
I would expect those three Net::FTP arguments to pair up with the following FTP commands: USER, PASS, and ACCT. |
| 10:52 |
Bmagic |
jeff: thanks! I don't think, in all my years, knew that FTP had a third thing |
| 10:52 |
|
briank joined #evergreen |
| 10:53 |
Bmagic |
So, I guess, Evergreen only* uses that field for this? I think a lot of folks are confusing the "account" field in the acq.edi_account table to have something to do with the EDI message generation. |
| 10:54 |
Bmagic |
our documentation says this "In the Account field, enter information supplied by your provider." https://docs.evergreen-ils.org/eg/docs/latest/admin/acquisitions_admin.html#_create_an_edi_account |
| 10:58 |
|
jeffdavis joined #evergreen |
| 10:58 |
|
troy joined #evergreen |
| 10:59 |
|
ejk joined #evergreen |
| 10:59 |
|
degraafk joined #evergreen |
| 11:00 |
|
eby joined #evergreen |
| 11:00 |
|
Christineb joined #evergreen |
| 11:02 |
|
sandbergja joined #evergreen |
| 11:15 |
|
dmoore joined #evergreen |
| 11:18 |
|
mantis1 joined #evergreen |
| 11:22 |
jeff |
I think that could be made more clear, and I'd even suggest re-ordering the fields in the admin UI. |
| 11:24 |
jeff |
I don't know what the practical impact is in supplying an account value to Net::FTP when it isn't required (hopefully it would only send it if/when the remote end asked for it after PASS), but there's lots of failure modes to be discovered, especially if the value you put in the Account field needs to go somewhere else (Vendor Account Number seems most likely). |
| 11:24 |
jeff |
I also don't know how often EDI vendors are using FTP with a required account (ACCT) value. |
| 11:25 |
sharpsie |
I'm working right now on a branch to reimplement the SFTP parts of that process since it doesn't seem to actually work and B&T(?) is moving to SFTP only soon |
| 11:26 |
sharpsie |
maybe a good hackaway project? |
| 11:28 |
Bmagic |
jeff: I agree with making that more clear, probably both in the UI and in the documentation. Reordering them in the UI to be more clear would be helpful as well. sharpsie: yes! |
| 11:29 |
Bmagic |
I have a related question: the note field in the provider/vendor MARC tag. I'm staring at the database, and I see an example of this having made it into the database from a MARC record. Evergreen successfully moved the data from the 962$p into the "note" column in the acq.lineitem_detail table |
| 11:30 |
Bmagic |
but does that "note" field die there? I don't see that it makes a note in asset.copy for the finalized copy |
| 11:43 |
|
dmoore joined #evergreen |
| 12:13 |
|
jihpringle joined #evergreen |
| 12:44 |
|
kworstell_isl joined #evergreen |
| 12:45 |
|
kworstell-isl joined #evergreen |
| 13:27 |
|
jihpringle joined #evergreen |
| 13:43 |
|
smayo joined #evergreen |
| 14:42 |
|
mantis1 left #evergreen |
| 15:09 |
|
mmorgan1 joined #evergreen |
| 17:02 |
jeffdavis |
There should be at least one entry in metabib.metarecord_source_map for every bib record, right? |
| 17:07 |
|
mmorgan1 left #evergreen |
| 18:11 |
berick |
jeffdavis: yes, for non-deleted bits |
| 18:11 |
berick |
*bibs |
| 18:13 |
jeffdavis |
thanks |
| 18:22 |
jeffdavis |
running into a situation on a 3.11 server where ingest is choking during upsert on metabib.browse_entry |
| 18:29 |
jeffdavis |
https://gist.github.com/jdavis-sitka/7b9da2965bb48fa5db19085f8061d4f8 |
| 18:31 |
jeffdavis |
if I'm reading this correctly, metabib.reingest_metabib_field_entries is failing on an upsert that was added to support queued ingest, but it's hard to tell why |
| 18:33 |
jeffdavis |
also hard to reproduce with concerto data |
| 18:37 |
jeffdavis |
aha! "ERROR: there is no unique or exclusion constraint matching the ON CONFLICT specification" |
| 18:40 |
jeffdavis |
we removed the unique constraint on metabib.browse_entry (sort_value, value) as a workaround for bug 1695911 |
| 18:40 |
pinesol |
Launchpad bug 1695911 in Evergreen "Long browse entries cause index row size error" [Undecided,New] https://launchpad.net/bugs/1695911 - Assigned to Chris Sharp (chrissharp123) |
| 18:41 |
jeffdavis |
none of the proposed fixes for that bug have worked for us so far, but I guess I'll try again |
| 18:43 |
jeffdavis |
and in fact I think none of the proposed fixes are compatible with the upsert statement as-is, because they also remove the constraint that the upsert depends on? |
| 18:59 |
|
jihpringle joined #evergreen |
| 19:25 |
|
sandbergja joined #evergreen |
| 20:01 |
|
book` joined #evergreen |
| 20:02 |
|
abneiman joined #evergreen |
| 20:05 |
|
jonadab joined #evergreen |
| 21:20 |
|
sandbergja left #evergreen |
