| 11:41 |
eeevil |
berick might know off the top of his head, though? |
| 11:46 |
berick |
ideally those params would be passed invididually to mkurl (inside the {}), but passing the params via the base URL string should also work |
| 11:46 |
|
mantis1 joined #evergreen |
| 11:48 |
mantis1 |
when testing action triggers/notices, what would it take for something to fall into 'invalid' status? |
| 11:49 |
berick |
mantis1: the event def will have a validator |
| 11:49 |
berick |
and its check(s) failed |
| 11:50 |
berick |
e.g. hold ready for pickup notice, but the hold was canceled in the meantime |
| 11:50 |
Dyrcona |
mantis1: The validator fails. Look at the event_definition and you can find the code somewhere under OpenILS/Application/Trigger/Validator.pm or OpenILS/Application/Trigger/Validator/* |
| 11:51 |
Dyrcona |
The event definition validator field value corresponds to a subroutine name. |
| 11:51 |
* Dyrcona |
is testing a custom db upgrade from 3.10.3 to main, and stuff keeps failing left and right. |
| 11:51 |
mantis1 |
I'm trying to test a pre-overdue but it seems like it should have passed |
| 11:51 |
mantis1 |
I checked out an item that would be due within the right time frame |
| 11:51 |
mantis1 |
but I'm also trying out a new HTML format for it |
| 11:52 |
Dyrcona |
What's the validator? |
| 11:52 |
mantis1 |
CircIsOpen |
| 11:56 |
Dyrcona |
Are there action_trigger.event_params entries specifying 'target_age_field' and 'min_target_age' for the event_definition? |
| 11:57 |
Dyrcona |
if target_age_field is missing, the delay_field will be used instead. |
| 11:58 |
Dyrcona |
if min_target_age is missing, it will fail to validate. |
| 12:03 |
mantis1 |
the thing is it does work but in a testing environment, it's just coming up invalid |
| 12:03 |
mantis1 |
not sure what the difference between this and production would be |
| 12:03 |
Dyrcona |
action_trigger.filters in /openils/conf ? |
| 12:05 |
mantis1 |
it's the same as production it looks like |
| 12:06 |
mantis1 |
also in that table, we have max_delay_age and min_target_age |
| 12:12 |
Dyrcona |
mantis1: if none of that turns out to be the issue, keep asking. I'll keep looking. :) |
| 12:12 |
mantis1 |
sorry how do you check for timezone in the GUI? I didn't see anything in the docs about it |
| 12:13 |
Dyrcona |
I use timedatectl on the command line |
| 12:14 |
mantis1 |
looks like it's set right; EDT |
| 12:14 |
mantis1 |
I also ran some tests with a notification from production on this server without any changes and it's also giving an invalid status |
| 12:14 |
Dyrcona |
OK. It's under Settings -> "Date & Time" in the GUI. |
| 12:15 |
Dyrcona |
There are some warnings you grep the logs for. |
| 12:16 |
Dyrcona |
"'min_target_age' parameter required for MinPassiveTargetAge validator" |
| 10:30 |
Dyrcona |
Makes sense, I guess. The database that I was messing with yesterday has been upgraded to main. |
| 10:30 |
* Dyrcona |
checks on not upgraded. |
| 10:30 |
Dyrcona |
I think it's time to play some Police: Too Much Information. :) |
| 10:35 |
Rogan |
Dyrcona it's always a good time for the Police (I'm fond of 80s music as a personal taste but the Police have stood the test of time IMO) |
| 10:45 |
pinesol |
News from commits: LP2067115: More fieldmapper comboboxes domId <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=d44e6b0da02c250fa6e233f38ff566aed86ca39d> |
| 10:45 |
pinesol |
News from commits: LP2067115: Fieldmapper should set combobox domId, not id <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=841a2281fb1727327bb15eb476c0406fed463616> |
| 10:56 |
|
Christineb joined #evergreen |
| 11:14 |
|
smayo joined #evergreen |
| 11:14 |
|
collum joined #evergreen |
| 11:25 |
smayo |
I've been trying to test a new function that should be on the AngularJS navbar (dark mode color switch) but none of my changes to navbar.js have been doing anything, and the function neither runs nor throws an error. I check the page sources and find that navbar.js is not there. But the navbar still does everything but the new stuff??? |
| 11:25 |
Bmagic |
seems like a dev environment issue? |
| 11:26 |
|
sleary joined #evergreen |
| 11:26 |
Bmagic |
the browser will omit loading JS files if they aren't syntactically sound |
| 11:30 |
smayo |
Will do |
| 11:33 |
smayo |
Environment does NOT load navbar.js with vanilla |
| 11:34 |
Bmagic |
does this: https://bugsquash.mobiusconsortium.org/eg/opac/home |
| 11:35 |
smayo |
It's not there on your test server either |
| 11:35 |
Bmagic |
if it's in eg2, then the filename won't surface the same on the browser, it's all compiled and boiled down into random js files, and some are combined into a single |
| 11:36 |
smayo |
I'm looking for it on the circ page |
| 11:37 |
smayo |
There IS a machine code-ish version of it in core.module.js, which IS included, but it doesn't have an individual file like, say, grid.js |
| 12:42 |
* JBoyer |
trips over a pile of helm charts, transpilers, and docker images and grumbles "When did people stop /writing software/ instead of orchestrating infrastructure to LARP Google 2.0?!" |
| 12:42 |
Dyrcona |
JBoyer++ |
| 12:43 |
Dyrcona |
Bmagic: Smells like WASM. :) |
| 12:43 |
* Dyrcona |
wonders why an event was not created in his test. |
| 12:46 |
Dyrcona |
hold.available is supposed to get created right away, no? |
| 12:50 |
Dyrcona |
The environment is set up. |
| 12:52 |
Dyrcona |
Yeahp. I can find it calling even.autocreate in the logs. |
| 13:04 |
Dyrcona |
Hrm... It says the hook is passive, but I'm copying values from another event with the same hook, and it doesn't have a max_delay.... |
| 13:06 |
Dyrcona |
And the hook doesn't exist.... |
| 13:06 |
* Dyrcona |
checks for typos. |
| 13:07 |
Dyrcona |
OK. It's an odd one: au.sms_text.test. That dot between text & test is usually a comma, and I should have copy and pasted instead of typing. |
| 13:07 |
Bmagic |
:) |
| 13:34 |
|
LindaJansova joined #evergreen |
| 13:36 |
* Dyrcona |
is having one of "those" days where the brain and fingers cannot get it together. typos-- |
| 13:38 |
pinesol |
Dyrcona: go with Stanely Kubrick |
| 13:38 |
Dyrcona |
pinesol: You have a very dark sense of humor. |
| 13:38 |
pinesol |
Dyrcona: As great as you are man, you'll never be greater than yourself. |
| 13:39 |
Dyrcona |
berick: Have you got a suggestion for running test SMS messages through the XML notice generator? I was thinking of running it once per minute, but I guess I'll have to check with Unique support about what they might expect. |
| 13:40 |
Dyrcona |
@decide underscore or comma |
| 13:40 |
pinesol |
Dyrcona: go with underscore |
| 13:41 |
Dyrcona |
pinesol++ |
| 14:21 |
Dyrcona |
I'm looking at curbside. (We have one library, at least, still using it.) I might need some new templates. |
| 14:21 |
Dyrcona |
Maybe not. |
| 14:39 |
Dyrcona |
"1, 2, 5!" |
| 14:49 |
Dyrcona |
hmm.. Don't think sending test SMS is gonna work this way. The staff client expect an almost immediate response. With NOOP_True, it will always report success won't it? |
| 14:51 |
Dyrcona |
Eh, no.... There's no template output, so the staff client will always report failure. Staff will not like that. |
| 14:59 |
berick |
Dyrcona: oh you're trying to use open-ils.actor.event.test_notification ? |
| 15:00 |
berick |
yeah that would take some changes to tie-in a 3rd party sms generator |
| 15:00 |
Dyrcona |
berick: No, the staff client uses it. I'm just trying to figure out how that would work. |
| 15:01 |
berick |
right, yeah, it should basically work, but like you said, the UI will not get the output it may currently be expecting |
| 15:01 |
Dyrcona |
That's the conclusion I'm coming to, unless we hack the staff client. |
| 15:02 |
Dyrcona |
It looks like it might only fire 1 event, even if two are configured... I should test that, though. |
| 15:02 |
Dyrcona |
I'll enable my test event and see what happens on a test system. |
| 15:07 |
Dyrcona |
With both events active, neither got created. |
| 15:11 |
Dyrcona |
The default event from Evergreen by itself works. My custom event does not. The latter reports a failure and the event fails to get created. I'll check if the validation needs anything, but I think the validator is NOOP_True. |
| 15:12 |
Dyrcona |
Huh... I wonder if I'm looking at the correct database... |
| 15:21 |
Bmagic |
ha! so that's what that column is for |
| 15:21 |
mmorgan |
:) |
| 15:21 |
Bmagic |
nope, not backdated |
| 15:22 |
Dyrcona |
On my events thing: with both events enabled only 1 fires. In any case the event that fires is set to complete, so we can't use this as-is for test text messages. |
| 15:22 |
Bmagic |
Dyrcona: that's what I was thinking |
| 15:22 |
Bmagic |
(on your thing) |
| 15:23 |
Dyrcona |
Yeah, I just had to run it to make sure. |
| 15:23 |
Dyrcona |
My test system does fire my test event with both enabled, but that's probably just "luck." |
| 15:30 |
mmorgan |
Bmagic: Is the max_fine in the circ properly set to 10? |
| 15:30 |
Bmagic |
mmorgan: yes |
| 15:30 |
Bmagic |
technicall 10.00 |
| 10:19 |
pinesol |
News from commits: LP2006969 (follow-up): fix a lint issue in MARC editor case statement <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ad1d4106a3013dfd1ae2fd44493e6d994f441309> |
| 10:20 |
berick |
don't forget https://en.wikipedia.org/wiki/Snarf_(ThunderCats) |
| 10:20 |
kmlussier |
heh |
| 10:29 |
Bmagic_ |
test |
| 10:29 |
Bmagic_ |
dang it, still have the tail |
| 10:29 |
Bmagic |
there |
| 10:30 |
Bmagic |
csharp_: sup? |
| 15:17 |
Dyrcona |
I wonder if it would make more sense to wrap a check for "if for_email" around the email address and the text_number below that with a "if for_text" wrapped around it in the template? |
| 15:18 |
Dyrcona |
Hm... That complicates the logic further doesn't it? Because it would seem natural to add another check around the block that prints the street address. |
| 15:23 |
Dyrcona |
Bmagic: I copied the minimum of that I think is necessary to the utilities repo. |
| 15:24 |
Dyrcona |
I also pushed a branch to github with the same changes on the a clone of berick's original repository: https://github.com/CWMARSINC/evergreen-xml-notices/tree/cwmars-test (I'm pretty sure that one is public.) |
| 15:27 |
* Dyrcona |
was going to use that on a test system to see how it works. Maybe I'll try that right now. |
| 15:28 |
|
jvwoolf joined #evergreen |
| 15:32 |
jvwoolf |
csharp_: Do all of the PINES libraries have LibraryIQ, or just some? |
| 15:33 |
csharp_ |
jvwoolf: at this point, just two |
| 15:45 |
|
jihpringle joined #evergreen |
| 15:53 |
jvwoolf |
csharp_: We have 4 including a big system. Helping them out with some location cleanup at this very moment, so they can make more use of the tool. |
| 16:07 |
|
jvwoolf left #evergreen |
| 16:33 |
Dyrcona |
Well, the test of hold ready for pickup notifications yielded an empty file because the test data is about 17 days out of date. :) |
| 16:36 |
Dyrcona |
I should add for_text to a couple more files.... I was gonna wing it by setting FOR_EMAIL to --for-text. :) |
| 16:43 |
Bmagic |
what's the setting/mechanism that warns catalogers that they are importing a duplicate in the z39.50 interface? |
| 16:48 |
Dyrcona |
I don't remember off the top of my head. I'd have to grep through the code to find it. |
| 09:59 |
|
sleary joined #evergreen |
| 10:00 |
|
kmlussier joined #evergreen |
| 10:00 |
|
mmorgan1 joined #evergreen |
| 10:22 |
Dyrcona |
Bmagic: I have not had a chance to test the 3.13 beta tarball, yet. I was going to do it first thing this morning, but stuff came up. |
| 10:32 |
Dyrcona |
@decide bookworm or jammy |
| 10:32 |
pinesol |
Dyrcona: go with jammy |
| 10:33 |
|
redavis joined #evergreen |
| 10:48 |
|
Christineb joined #evergreen |
| 11:39 |
Dyrcona |
I'm doing it all by hand from the tarballs. I've got OpenSRF 3.3.0 up and running and test pass, but we knew that should work. |
| 11:42 |
kmlussier |
Dyrcona: It never hurts to double check just in case something changed. |
| 11:44 |
Dyrcona |
True. |
| 12:07 |
|
jihpringle joined #evergreen |
| 13:02 |
|
cbrown-isl joined #evergreen |
| 13:12 |
Dyrcona |
So picky... Have to remember to run autogen.sh and restart apache2. |
| 13:18 |
|
dmoore joined #evergreen |
| 13:27 |
Dyrcona |
Bmagic: All Perl and pgtap tests pass with the 3.13 beta tarball on a fresh installation. |
| 13:27 |
|
kworstell-isl joined #evergreen |
| 13:28 |
Dyrcona |
I'll give the db upgrade a whirl |
| 13:41 |
Dyrcona |
The db upgrade seems to work. |
| 13:42 |
|
sandbergja joined #evergreen |
| 13:43 |
sandbergja |
berick: trying to set up a redis dev environment, and osrf_control -l --start-all gave me the error "[auth] ERR Protocol error: invalid bulk length, at /usr/share/perl5/Redis.pm line 311." Does that sound familiar at all? |
| 13:48 |
Dyrcona |
So, after doing a db upgrade, the following pgtap tests fail: t/lp1371647_add_fixed_fields.pg and t/lp1588543_marc_record_attributes.pg. I'm not sure we really care about running tests after doing an upgrade, so don't let that hold up the release. |
| 13:49 |
* Dyrcona |
did the db upgrade twice to make sure the failure was consistent. |
| 13:50 |
Dyrcona |
sandbergja: When I've had an auth error with Redis, I've usually forgotten to update the opensrf_core.xml file. |
| 13:52 |
sandbergja |
Dyrcona++ |
| 15:19 |
redavis |
!!! |
| 15:19 |
Bmagic |
#link https://evergreen-ils.org/downloads/Evergreen-ILS-3.13-beta.tar.gz |
| 15:19 |
sandbergja |
nice! woohoo! |
| 15:20 |
Bmagic |
If anyone has some time, testing that would be sweet |
| 15:20 |
mmorgan |
Bmagic++ berick++ shulabear++ sleary++ abneiman++ |
| 15:20 |
dluch |
releaseteam++ |
| 15:20 |
redavis |
Bmagic++ berick++ shulabear++ sleary++ abneiman++ |
| 15:30 |
redavis |
That was my thinkin's. Cool. Thanks for the spell wisdom. Makes sense. |
| 15:30 |
Bmagic |
ok, that's another branch to merge..... |
| 15:30 |
Bmagic |
someone else should probably do it |
| 15:30 |
Dyrcona |
FWIW, I don't disable JIT on my test db with Pg12+. |
| 15:31 |
csharp_ |
I would have to watch a tutorial - my scant reading doesn't have me grokking it yet |
| 15:31 |
Bmagic |
(since I authored it) - anyone want to take the action item? |
| 15:31 |
csharp_ |
could be one of those things that tests fine but causes havoc at scale |
| 15:31 |
Bmagic |
or I guess I should back up and ask if it needs* to make it in before 3.13 is official |
| 15:32 |
csharp_ |
I think since PG11 is dead, we should push it asap |
| 15:32 |
Dyrcona |
csharp_: Depends on a number of factors from what I understand. |
| 15:40 |
csharp_ |
1 bug <--> 1 issue is the kind of granularity I try for |
| 15:40 |
mmorgan |
Commits can get missed. |
| 15:40 |
csharp_ |
but I'm not developing big ol' UIs and things |
| 15:40 |
kmlussier |
But if the commit with the shared component is added to a specific launchpad bug, and then somebody has feedback on that shared component as part of testing, won't that discussion be on that specific LP bug even if it's for a distinct feature? |
| 15:40 |
csharp_ |
mmorgan: I agree |
| 15:41 |
kmlussier |
csharp_: So are you saying those shared components should get their own distinct bug? |
| 15:41 |
redavis |
(s/omnibus bus (that's funny)/omnibus bug) |
| 15:44 |
csharp_ |
there's not a consensus for anything |
| 15:45 |
mmorgan |
Extra intermediate work may save work further down the line... |
| 15:45 |
csharp_ |
yeah, and hints in the bug comments usually say "the top 10 commits on <branch>" |
| 15:45 |
eeevil |
if all commits on a branch attached to an LP must have that LP prefix before being pushed to working, I'm fine with that rule. but that's not ... what I though the rule was, and wanted to avoid extra work that would 1) delay testing 2) make everyone that wanted to look at it move to another branch |
| 15:45 |
redavis |
Does it need to be a vote? since it's already in the guidelines? |
| 15:45 |
berick |
i don't think we're talking about working bracnches eeevil |
| 15:45 |
berick |
just the final product |
| 15:50 |
shulabear |
https://wiki.evergreen-ils.org/doku.php?id=newdevs:git:create |
| 15:50 |
eeevil |
(and, yeah, I do think the committer can amend the commits as appropriate -- or ask the author for a cleanup "final" branch) |
| 15:50 |
Dyrcona |
kmlussier: I do, but I don't use it any more. I do this `git cherry-pick ^HEAD working/user/whoever/branch` |
| 15:51 |
Dyrcona |
Or, I check out the branch and rebase on master. That's why I don't like extraneous commits, i.e. not related to what's being tested. |
| 15:51 |
csharp_ |
I've been doing 'git cherry-pick commit1^..commit10', but I'll experiment with Dyrcona's method |
| 15:52 |
Bmagic |
Dyrcona: I could see an issue with that command if the working branch was based on a different working branch? That would bring in more than just the feature you wanted to checkout? |
| 15:52 |
Dyrcona |
Yes, you have to start from the same or similar bases. |
| 07:59 |
|
BDorsey joined #evergreen |
| 08:18 |
|
kworstell-isl joined #evergreen |
| 08:34 |
|
mmorgan joined #evergreen |
| 08:45 |
mmorgan |
rlefaive: bug 1993824, released in 3.12 resolved those issues. I did a quick test on a test server and was able to download csv and delete a session. |
| 08:45 |
pinesol |
Launchpad bug 1993824 in Evergreen "wishlist: Angular Link Checker Interface" [Wishlist,Fix released] https://launchpad.net/bugs/1993824 |
| 08:50 |
|
Dyrcona joined #evergreen |
| 08:57 |
|
dguarrac joined #evergreen |
| 11:49 |
Dyrcona |
I think verify_passwd requires a hash of the password. |
| 11:51 |
csharp_ |
or the salt |
| 11:51 |
Bmagic |
looking at the function, maybe I can delete the row in actor.passwd? |
| 11:52 |
Dyrcona |
Bmagic: actor.change_password worked for me yesterday on a system that's running main from early last month. I changed a patron's password on the test system to play with NCIPServer authentication. |
| 11:52 |
Dyrcona |
I could login with the new password. |
| 11:53 |
Bmagic |
no go on my test machine. Tried srfsh also |
| 11:54 |
Bmagic |
srfsh# login admin demo123 |
| 11:56 |
Bmagic |
something is afoot |
| 11:56 |
Bmagic |
I'm sure it's me, crawling logs |
| 15:57 |
Dyrcona |
I don't think there can be one because acn doesn't have a field that links to actor.usr, but I could be wrong. |
| 15:58 |
jmurray-isl |
I was wondering. The template gets its user info from the user_data variable, instead. |
| 15:59 |
Dyrcona |
Yeah. Evergreen supplies the user data when the event is created. |
| 16:00 |
jmurray-isl |
In addition to that one, the Send Test SMS action trigger (hook: au.sms_text.test) doesn't seem to have context_usr_path defined either, but the primary target should be actor.usr.id. I've tried various things, but nothing has worked to populate that one, either. |
| 16:00 |
Dyrcona |
For that event, you only get the carrier and the number. |
| 16:02 |
Dyrcona |
My previous comment was for texting a call number. |
| 16:02 |
Dyrcona |
For au.sms_text.test the core type is au. |
| 16:02 |
jmurray-isl |
Yep, I've tried, target, target.id, and id and none seem to work. |
| 16:03 |
Dyrcona |
What's your ultimate goal? |
| 16:04 |
jmurray-isl |
To populate context_user on SMS action trigger events so I can reference them in an SQL query daily report on the counts of SMS events to various carriers |
| 16:05 |
jmurray-isl |
Those two action trigger definitions were the outliers. |
| 16:06 |
jmurray-isl |
Their number is minimal, to be fair, but I was mostly wondering for completion sake. |
| 16:09 |
Dyrcona |
For the send test sms, you can use the target in your SQL. |
| 16:10 |
jmurray-isl |
Yep. |
| 16:11 |
Dyrcona |
I don't think you can get anything in the text call number event context_usr without changing Perl code. |
| 16:11 |
jmurray-isl |
Gotcha. |
| 16:19 |
JBoyer |
FYI for GitLab hosters, they’ve laid a security egg re: password resets: https://arstechnica.com/?p=2021409 |
| 16:19 |
JBoyer |
Update asap |
| 16:19 |
|
jihpringle joined #evergreen |
| 16:23 |
Dyrcona |
jmurray-isl: Yes. It's pulled from the target using the context_usr_path. Since the usr is the target for the test sms event, it's not possible to grab it. Look at OpenILS/Application/Trigger/Event.pm around line 496. |
| 16:25 |
Dyrcona |
jmurray-isl: When you tried id on the send test sms, did you restart the open-ils.trigger service after making the change? "id" might work on that one since the core_type is au. |
| 16:27 |
jmurray-isl |
I did not restart the service. I'll try that. |
| 16:30 |
Dyrcona |
I was trying to test it, too, but I didn't set websockets port last time that I built opensrf for debuggin. |
| 16:34 |
Dyrcona |
then a hard reload in Chrome... |
| 16:38 |
Dyrcona |
Context user was filled in with the wrong id, and the event errored. |
| 16:40 |
Dyrcona |
Nope. I take that first part back. context_user was not set. The event did error. |
| 12:18 |
dickreckard |
Bmagic: a new clean database works correctly with the current Evergreen bits. it seems to be the upgraded db that breaks the keyword search ( and probably other things then. ) |
| 12:18 |
Bmagic |
I see what you mean, carry on |
| 12:26 |
|
smayo joined #evergreen |
| 12:49 |
Dyrcona |
I have test/dev servers where features sometimes don't work. I've got one where the acq. interface completely fails. Search has been a problem in the past. A full ingest sometimes helps. |
| 12:49 |
Dyrcona |
dickreckard ^^ |
| 12:57 |
Dyrcona |
We usually blame these issues on the test environment being slower than production. |
| 14:05 |
|
sleary joined #evergreen |
| 14:54 |
Dyrcona |
oops. accidentally pushed a working branch to NCIPServer origin, and gitolite won't let me delete it. I should probably check/update the configuration to prevent pushing working branches in that repo. There's only 3 of us that use it, anyway.... |
| 15:09 |
|
kworstell-isl joined #evergreen |
| 16:06 |
Dyrcona |
I guess a username that's 14 digits will cause us problems.... I've recently come out against letting patrons chose their own usernames in light of these issues and other bugs. |
| 16:07 |
Dyrcona |
I've been outvoted, so I go along with it. |
| 16:08 |
Dyrcona |
Stompro: Do you want to update the code or should I? |
| 16:09 |
Stompro |
Feel free, I'll hopefully be able to test it out tomorrow afternoon. I don't get why usernames don't actually work either, that might be a different bug. |
| 16:10 |
Dyrcona |
Well my barcode == username, and breaks the rules. I should have tested with a regular patron, and in light of this, I will test it again. |
| 16:11 |
Dyrcona |
I think I know the account to test with. One of those with the lowercase d in the barcode. They also have a different username. |
| 16:13 |
Dyrcona |
Hm.. the lowercase d password is inactive in my test database and the uppercase D one is active. I guess that's even better. :) |
| 16:17 |
Dyrcona |
Also, the code was implemented to only expect barcodes, but.... |
| 16:21 |
Stompro |
do you mean the "<AuthenticationInputType>barcode</AuthenticationInputType>" part? |
| 16:22 |
Stompro |
I noticed that also, but I don't remember what the other options in the standard were there off the top of my head. |
| 12:00 |
|
jihpringle joined #evergreen |
| 12:10 |
Bmagic |
Dyrcona: I'm troubleshooting the SFTP ingram sftp thing. I've successfully logged into their server using a GUI tool, but the funny thing is, their server is sending my GUI tool a banner message. Which, I think, is tricking the Evergreen code. We're able to push orders, but we can't receive. When attempting to scp manually via scp command, I get this: "exec request failed on channel 0" - which is their server attempting to use my tty ( |
| 12:10 |
Bmagic |
according to google) |
| 12:11 |
Bmagic |
did you deal with this during testing? |
| 12:11 |
berick |
hm, just deployed locally. i've only testing sending so far. |
| 12:11 |
berick |
*tested |
| 12:13 |
Bmagic |
bouncing this off of you: scp account_redacted ftp.ingramcontent.com:/outgoing/filename_redacted.EIN ./test.ein |
| 12:13 |
Bmagic |
does that look sound? |
| 12:14 |
Bmagic |
(it prompts for the password) - which I provide, then I get the "exec request failed on channel 0" error |
| 12:16 |
berick |
Bmagic: that fails for me too, but using "sftp" instead of "scp" works OK |
| 15:20 |
|
kworstell-isl joined #evergreen |
| 16:21 |
Stompro |
I think the fake ISBN's that B&T creates for DVDs are not conflicting with real codes. Looks like Romania and Argentina were assigned 630 and 631 in 2023. |
| 16:21 |
Stompro |
s/are not/are now/ |
| 16:36 |
Stompro |
But, a test system with ISBN::Data from 2021 also doesn't load them... so maybe something else is causing this. |
| 16:39 |
Dyrcona |
Fake ISBNs were problem never a good idea. |
| 16:40 |
Dyrcona |
s/problem/probably/ but somehow problem is more appropriate though is not an adverb. |
| 16:50 |
mmorgan |
probably a problem |
| 15:37 |
Bmagic |
I think* it was saving a bib record, which in-turn queried reporter.old_super_simple_record - which is what's written on the bug report |
| 15:37 |
eeevil |
there are certain things that JIT wants to do that we have already poured a lot of brain power into manually tuning |
| 15:37 |
Bmagic |
that makes sense |
| 15:38 |
eeevil |
it's not that EG is incompatible with PG's JIT, it's that (just like autovac and stats targets, and lots of other stuff, tbh) it requires config that is tuned to your particular size and shape of data |
| 15:39 |
eeevil |
a small EG instance may benefit a BUNCH from JIT, and reporting might as well (I've tested neither, but I have suspicions) |
| 15:40 |
sandbergja |
thanks, eeevil, that's helpful info to have |
| 15:40 |
eeevil |
but(!) unless someone has the tuits to learn the feature well, and analyze our queries in that context, I agree that we should recommend disabling JIT for now |
| 15:40 |
Bmagic |
eeevil++ |
| 15:41 |
eeevil |
I'd actually propose we investigate (as a community, as broadly as we can manage) cross-column stats targets before jumping into JIT |
| 15:41 |
Dyrcona |
I'm OK with that, but I don't think I've every encountered an issue caused by JIT. Pg 16 (even unoptimized) has pretty much always been faster than Pg 10 for me. BUT! I've not run it in produciton, just in testing on a production-sized database with a production-sized server. |
| 15:41 |
eeevil |
(not to derail the JIT-specific discussion, but as a query tuning tool I think that will pay off for more folks) |
| 15:42 |
eeevil |
Dyrcona: I haven't seen JIT-specific issues either, but I think we can be fairly sure that plan stability is /higher/ without JIT (until we learn to tune it well) |
| 15:43 |
Bmagic |
Disabling it fixed our problem on a test-then-production instance |
| 15:43 |
Bmagic |
pretty sure it manifested as a time-out when clicking on save in the MARC editor |
| 15:43 |
Dyrcona |
So, we'll recommend disabling JIT in the installation instructions, then. |
| 15:43 |
eeevil |
which is to say, yes, some folks will lose out on some optimizations they get "for free" with JIT on, but things are much less likely to go sideways in ways some have seen |
| 07:53 |
|
collum joined #evergreen |
| 07:58 |
|
BDorsey joined #evergreen |
| 08:36 |
|
Dyrcona joined #evergreen |
| 08:42 |
Dyrcona |
Guess, I'll undo my testing changes on the test database and try the fetcher with the production settings and grab the files from Ingram's server. Maybe there's something that my test changes are masking. |
| 08:43 |
Dyrcona |
I did add vsftp on my sftp host, and configured one account to get files with ftp and others with sftp and that did not seem to cause files to be downloaded more than once in my test environment. I thought that using ftp and sftp with basically the same account would do it, but it didn't. |
| 08:46 |
Dyrcona |
I have also verified that FTP is working. |
| 09:03 |
Dyrcona |
Feels like there should be a way to do this with pg_dump/pg_restore, but so far no dice. I think I'll try a data-only dump with --disable-triggers and a truncate on the tables after. |
| 09:11 |
Dyrcona |
pg_dump: warning: there are circular foreign-key constraints among these tables: |
| 10:12 |
berick |
been meaning to move in that direction myself |
| 10:13 |
Dyrcona |
OK. I guess we agree more than I thought yesterday. |
| 10:13 |
berick |
also considering keeping local copies of the plain files -- before they go into the DB -- as a secondary backup for debugging, etc. |
| 10:13 |
Dyrcona |
I still haven't been able to replicate what I saw in production on my test environment, so I'm trying to restore the original settings. I'm running the fetcher to get caught up. |
| 10:14 |
berick |
possibly a lighter way to say "we already have this" than querying the DB |
| 10:14 |
Dyrcona |
Yeah, that is worth exploring. |
| 10:15 |
Dyrcona |
Back to the issue, I thought it must have to do with 1 account having sftp in the host and the others having ftp with the same credentials and directory, but even when I did that on my test setup, it didn't pull the files twice. |
| 10:16 |
Dyrcona |
This other account says X of 1722 targets.... |
| 10:34 |
|
jvwoolf joined #evergreen |
| 10:45 |
Dyrcona |
Ok. I've got only the Ingram accounts set to active. I did a run to get caught up and grabbed 63 files. The second run grabbed 0. Now, I'm going to set 1 account to sftp in the host and see what happens. There are other accounts with the same credentials using FTP. This should replicate what we saw in production. |
| 10:48 |
|
sandbergja joined #evergreen |
| 10:54 |
Dyrcona |
Files retrieved: 275 |
| 10:55 |
Dyrcona |
Wow! I think it is the host part of the duplicate check in retrieve_core after all. Dunno why it didn't trigger on my local test server, though. |
| 10:56 |
Dyrcona |
berick: I think we should regexp_replace('^[a-z]+://', host, '') in the host check, or we just need to update all of the same accounts at once? |
| 10:57 |
Dyrcona |
or, maybe [^:]+ instead of [a-z]+? |
| 10:58 |
Dyrcona |
I'm running the same again to see what happens. I suspect it should grab 275 again unless a new file has gone up. |
| 11:45 |
Dyrcona |
csharp_: We had something local that was written in PHP. Now, we're using Metabase. |
| 11:45 |
Dyrcona |
It's not built into Evergreen, though you could add links. |
| 11:46 |
Dyrcona |
So, setting all of the accounts with the same username and password to use sftp resolves the multiple files retrieval, as I thought it might. |
| 11:48 |
Dyrcona |
Moral of the story: Don't just set 1 account to SFTP to "test" it. It's all or nothing. |
| 11:51 |
jeff |
and take steps to ensure that nothing tries to fetch files while you make the config changes to all the accounts in question? |
| 11:52 |
Dyrcona |
jeff: A SQL update should be fast enough and much faster than doing it in through the client. |
| 11:54 |
Dyrcona |
I may suggest a small path to O::A::Acq::EDI.pm to remove the scheme from the URL stored in host field of acq.edi_account. Doing a schemeless comparison would also resolve the issue. |
| 15:40 |
StomproJ |
Yes, for a number of years. |
| 15:40 |
Bmagic |
StomproJ++ |
| 15:40 |
Bmagic |
we gotta get this merged then |
| 15:41 |
StomproJ |
Works for SMS call number also, and for the SMS test message.... although there is a bug there I need to document. |
| 15:42 |
Bmagic |
I'm reading https://gitlab.com/LARL/evergreen-larl/-/commit/73b424779e2a07e351cc5cd78c8c2ee32b12fd6e |
| 15:43 |
StomproJ |
Testing is probably hard since you need a flowroute account setup with real money involved. Plus all the SMS Campaign registration stuff. |
| 15:44 |
Bmagic |
right, so, it'll never get merged.... how do we "trump" that? |
| 15:44 |
Dyrcona |
From what I understand, the campaign registration is pretty much required if you want your messages to get through, even with the commercial gateway. |
| 15:44 |
StomproJ |
Oh, I need to update it for the latest version of their API also, which improves the delivery report data. |
| 15:45 |
Dyrcona |
Bmagic: You've got the power.... |
| 15:45 |
Bmagic |
the branch needs documentation and probably a pg test and a perl test |
| 15:46 |
Dyrcona |
EDI is also hard to test. |
| 15:47 |
StomproJ |
I could probably provide api keys for someone to test... I'll have to think about how to do that. |
| 15:48 |
Bmagic |
StomproJ++ |
| 15:48 |
Dyrcona |
I wouldn't want anyone to get in trouble for sharing test API keys. |
| 15:48 |
Bmagic |
maybe we could create a trial account for testing |
| 15:49 |
StomproJ |
I'll reach out to Flowroute and see if they can provide trial accounts. |
| 15:50 |
Bmagic |
Flowroute might get an increase in business, which makes it feel "icky" to only support them, but we gotta start somewhere |
| 15:50 |
Dyrcona |
There's precedent with stripe. Someone with an account has to test it. |
| 15:51 |
Dyrcona |
Well, that's the code that there is, supplied by a community member. I don't see anyone else sharing anything. (Says the guy who's not a fan of commercial solutions in general, but in this case, what can you do?) |
| 15:55 |
Bmagic |
I prefer Evergreen to talk to a commercial SMS API, rather than generate XML and ship that to MessageBee (for example) |
| 15:56 |
Bmagic |
Shipping XML and maintaining a bunch of AT template toolkit's is more annoying IMO |
| 15:59 |
StomproJ |
I'm using a php script to just send them to my email now. You just tell flowroute your callback url. |
| 16:00 |
Dyrcona |
"Click here to spam the world" |
| 16:00 |
Bmagic |
What's the next step to get this Flowroute code merged? We have a bug, and the code, though the code isn't in the "normal" form/branch method? A signoff maybe? It could use the documentation pieces (release notes, and proper doc injections). I'm sure everyone would welcome such an addition, and the SMS fire has been burning for a long time now |
| 16:01 |
Dyrcona |
Bmagic: You just said it. It needs signoff and release notes minimum. Tests and documentation would be most welcome. |
| 16:02 |
Bmagic |
Seems pretty doable to get it over the finish line IMO. StomproJ: maybe we can divide the tasks? |
| 16:04 |
Bmagic |
I think it would be "easier" (for me) if it were in the working repo |
| 16:04 |
StomproJ |
Sure, I think just having someone else interested in it helps... Probably docs on setting up a flowroute account also... |
| 16:17 |
Bmagic |
sweet, StomproJ: you good with rolling with the collab branch? |
| 16:17 |
StomproJ |
Sure, sounds good. |
| 16:17 |
Dyrcona |
Bmagic++ StomproJ++ |
| 16:18 |
Bmagic |
Sounded like you were interested in the documentation additions, and release notes? I can try my hand a tthe tests |
| 16:18 |
StomproJ |
Here are all the flowroute related commits that I have in our custom production repo. https://gitlab.com/LARL/evergreen-larl/-/commits/rel_3_11_1-larl?search=flowroute |
| 16:19 |
Bmagic |
StomproJ: I think/hope those are the exact commits I just put onto our collab branch |
| 16:19 |
Dyrcona |
https://gitlab.com/LARL/evergreen-larl/-/commit/3d4cdbc7d6260640e5f086c2965dccc3797e27d1 isn't in the collab branch, and I wonder if it is necessary. |
| 13:32 |
berick |
Dyrcona: i'd stop short of deleting the files after download since that's new behavior, but fixing the dupe detection is obv. critical. |
| 13:33 |
Dyrcona |
In the long run, I think we should delete the files, or make it an option. As far as I can tell, Ingram isn't cleaning up the outgoing directory. I have not checked other vendors, yet. |
| 13:34 |
Dyrcona |
So, I'll agree with that not being a bug fix. |
| 13:36 |
Dyrcona |
Meanwhile, I can test with local servers and messages from production. |
| 13:36 |
Dyrcona |
Wonder if the fetcher works with the debugger? |
| 13:47 |
Dyrcona |
I swear that I saw the duplicate detection code last week, but can I find it right now? Nope. |
| 13:48 |
Dyrcona |
It's probably in OpenILS::Application::Acq::EDI->process_retrieval |
| 15:26 |
|
jvwoolf joined #evergreen |
| 16:03 |
|
sandbergja joined #evergreen |
| 16:11 |
|
jvwoolf joined #evergreen |
| 16:30 |
Dyrcona |
OK. I cannot reproduce the duplicate retrieval in any of my 3 test environments with recent files. |
| 16:31 |
Dyrcona |
This requires further investigation. |
| 16:52 |
Dyrcona |
Well, that's that fo today. |
| 16:59 |
|
Guest21 joined #evergreen |
