| 10:20 |
Dyrcona |
ian1: Do you mind pasting the command line you used? |
| 10:21 |
ian1 |
perl Open-ILS/src/support-scripts/eg_db_config --update-config --service all --create-database --create-schema --create-offline --user evergreen --password ******* --hostname localhost --port 5432 --database everdb --admin-user evergreen --admin-pass ********* |
| 10:22 |
Dyrcona |
Two suggestions: 1. if there is no other database on here, name the database "evergreen" it will save you issues with psql. |
| 10:23 |
Dyrcona |
2. Set the --admin-usr to "admin" and the --admin-pass to "demo123". This way, you can run the automated tests and they will just work. |
| 10:23 |
ian1 |
I can just run it again right? |
| 10:23 |
Dyrcona |
I guess a third suggestion: Add --load-all-sample to get some sample data in the database, unless you intend to build your data from scratch. |
| 10:24 |
Dyrcona |
You can, but I'd drop everdb, first : psql -U evergreen -h localhost -d postgres -c 'drop database everdb;' |
| 10:45 |
Dyrcona |
huh.... |
| 10:45 |
Dyrcona |
At this point, I'm stumped. |
| 10:45 |
Dyrcona |
I'd need to see the configuration files. |
| 10:46 |
Dyrcona |
Did you test OpenSRF before with the math add test from the OpenSRF README? |
| 10:46 |
ian1 |
I did that yesterday and at the time it worked fine |
| 10:46 |
Dyrcona |
So, you have /etc/ld.so.conf.d/opensrf.conf, then.... |
| 10:47 |
Dyrcona |
Is this Ubuntu 24.04? |
| 15:31 |
abneiman |
it's certainly a start |
| 15:31 |
abneiman |
jeffdavis++ |
| 15:31 |
Dyrcona |
For testing, we do have this old document: https://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa |
| 15:31 |
Dyrcona |
It basically says, you must include tests. |
| 15:32 |
jeffdavis |
I think " a plan for how to test if the fix works" is not necessarily the same as the automated tests contemplated there. |
| 15:32 |
jeffdavis |
Although automated tests are certainly ideal. |
| 15:32 |
sleary |
correct. |
| 15:32 |
abneiman |
yes, I was going to say - not everything is automatically-testable |
| 15:32 |
redavis |
I think there are both code tests and feature tests. |
| 15:33 |
sleary |
and I think that document is not entirely up to date with our current translation process. |
| 15:33 |
abneiman |
and in fact, we do have a "needstest" LP tag which indicates that an automated test is needed (and is often misapplied by people who think it means "please test this") |
| 15:34 |
sandbergja |
It seems to me that the automated test part of that document has been more or less ignored for 9 years... It is pretty unusual to see any code submitted _with_ automated tests. |
| 15:34 |
|
kworstell-isl joined #evergreen |
| 15:34 |
Dyrcona |
True. We have not been enforcing it. Commit messages explaining how to test have been acceptable, too. |
| 15:34 |
redavis |
there's a nuance differentiating needstest and needstestplan |
| 15:36 |
|
Jaysal joined #evergreen |
| 15:36 |
Dyrcona |
I'm not sure we were all that strict with the 2.8 and 2.9 releases mentioned in the document, but it's a start. |
| 15:36 |
|
Jaysal joined #evergreen |
| 15:36 |
sandbergja |
I'm hearing no strong objections to a needstestplan tag |
| 15:37 |
redavis |
+1 to needstestplan tag |
| 15:37 |
sandbergja |
And the page Dyrcona mentioned has a nice example of a test plan in a commit message |
| 15:37 |
redavis |
It seems that that page could also do with a nice update, but I can't volunteer for that. |
| 15:37 |
abneiman |
no, but I will point out that with one exception, the needstest tag is on bugs that haven't seen any action in 3+ years |
| 15:39 |
* mmorgan |
likes the idea of using Launchpad tags, but we need to make sure the tags are more like action items than reasons to kick the can down the road. |
| 15:39 |
abneiman |
this ^^^^ |
| 15:39 |
redavis |
abneiman, I can envision the needstestplan used on a consternating lp ticket during BSW where a tester might need more info to set up their test. "help me!" |
| 15:39 |
abneiman |
good point, redavis |
| 15:40 |
jeffdavis |
I will say I committed something today because abneiman asked for eyes on the 3.14 roadmap, and the fix had a test plan and no merge conflict. |
| 15:40 |
abneiman |
"The disambiguation of uses of Lauchpad tags: an Evergreen Conference Panel and / or drinking game" |
| 15:40 |
redavis |
lol! |
| 15:40 |
abneiman |
jeffdavis++ |
| 15:42 |
mmorgan |
+1 |
| 15:42 |
smayo |
sleary++ |
| 15:42 |
abneiman |
well, in that case, "needswork" and "needsrebase" should also be on that list |
| 15:42 |
sandbergja |
One etiquette question (which I think might be part of not kicking the can down the road): if a pullrequest gets a needstestplan applied, can anybody reply on launchpad with the test plan? Or would it have to tbe the original patch author. |
| 15:43 |
mmorgan |
I also like the idea of a bugs to look at list. |
| 15:43 |
redavis |
that's a cool idea. clarifying question - would needstestplan only go on pull requested tickets? |
| 15:43 |
redavis |
sandbergja++ |
| 15:43 |
sleary |
redavis I think so |
| 15:43 |
redavis |
sleary++ |
| 15:43 |
shulabear |
redavis++ |
| 15:44 |
Dyrcona |
sandbergja: In keeping the bazaar atmosphere, I think anyone could offer a test plan, though it would be better coming from the original patch author. |
| 15:44 |
abneiman |
yes, I was basically typing what Dyrcona just said re test plan |
| 15:44 |
redavis |
Dyrcona++ |
| 15:44 |
mmorgan |
I also think anyone could offer a test plan. |
| 15:44 |
sandbergja |
Dyrcona++ |
| 15:44 |
shulabear |
Dyrcona++ |
| 15:44 |
abneiman |
and +1 to the tag being only applicable to pr'd items |
| 15:45 |
jeffdavis |
IMO it should be an expectation that the author provides the test plan, but I agree anyone could do it. |
| 15:45 |
abneiman |
OK, so, I think we have a few items of agreement here: |
| 15:45 |
redavis |
And maybe worth noting that there might be people who excel at test plans but not other stuff and vice versaish. |
| 15:45 |
shulabear |
redavis++ |
| 15:45 |
sandbergja |
redavis: good point |
| 15:46 |
sleary |
I think we've occasionally gotten test plans from the first signoff person. |
| 15:46 |
abneiman |
1) [someone] will create a needstestplan tag, which will be appplied to PR'd bugs if a test plan is lacking and needed; 2) we prefer if all PR'd bugs ALREADY have a test plan from the patch author, but if not, anyone can provide them; 3) mmorgan will update the LP stats monthly pull to include new uses of needswork, needsrebase, and needstestplan |
| 15:46 |
mmorgan |
Providing test plans could be a good fit for folks that use Evergreen and not so much write code. |
| 15:47 |
abneiman |
is that an accurate summary? does anyone want to take the first item as an action? |
| 15:48 |
abneiman |
sandbergja++ # the best kind of action items are the ones already done! |
| 15:48 |
abneiman |
ok, for the minutes: |
| 15:48 |
redavis |
sandbergja++ |
| 15:49 |
abneiman |
#info agreed upon the following: 1) sandbergja will create a needstestplan tag, which will be appplied to PR'd bugs if a test plan is lacking and needed; 2) we prefer if all PR'd bugs ALREADY have a test plan from the patch author, but if not, anyone can provide them; 3) mmorgan will update the LP stats monthly pull to include new uses of needswork, needsrebase, and needstestplan |
| 15:49 |
terranm |
It will need to be added to https://wiki.evergreen-ils.org/doku.php?id=dev:lp_tags as well - I can do that |
| 15:49 |
abneiman |
terranm++ |
| 15:49 |
redavis |
terranm++ |
| 15:49 |
Dyrcona |
I think there's actually and #agreed command for the bot. |
| 15:49 |
abneiman |
moving along, or any other discussion here? did we meet your goal of bitesize actionable items here, sandbergja? |
| 15:49 |
Dyrcona |
s/and/an/ |
| 15:49 |
terranm |
To make sure I'm right, needstestplan should be applied to tickets needing testing instructions, correct? (I had to step away, so trying to catch up)_ |
| 15:50 |
sleary |
yes |
| 15:50 |
terranm |
thx |
| 15:50 |
sandbergja |
I'm good! Thanks all! |
| 15:56 |
redavis |
jeffdavis, that's preferable. |
| 15:57 |
Dyrcona |
Regarding Lp 2043142: Someone at CW MARS told me it likely would not affect us because we don't let library staff create templates. Otherwise, we would probably have tested it by now. |
| 15:57 |
pinesol |
Launchpad bug 2043142 in Evergreen "wishlist: Reports security improvements" [Wishlist,New] https://launchpad.net/bugs/2043142 |
| 15:57 |
sandbergja |
out of curiosity, does bug 2043142 have a test plan? |
| 15:58 |
abneiman |
sandbergja: there is a tech ref doc and an extensive commit message, but not necessarily a "do A and get B" test plan |
| 15:58 |
Dyrcona |
I have actually been looking at Lp 2060734, and I should go ever it again. I think I'd like to suggest/make some modifications. |
| 15:58 |
pinesol |
Launchpad bug 2060734 in Evergreen "Various changes to the release process" [Undecided,Confirmed] https://launchpad.net/bugs/2060734 - Assigned to Jason Stephenson (jstephenson) |
| 15:59 |
abneiman |
which, does point to a wrinkle that I of all people should've thought of, which is, what's the difference between a bugfix test plan and a feature test plan |
| 15:59 |
Dyrcona |
typos-- |
| 15:59 |
sandbergja |
Dyrcona++ # thanks for reviewing that |
| 15:59 |
Dyrcona |
sandbergja++ Thanks for taking it on. |
| 15:59 |
sandbergja |
abneiman: good question |
| 16:00 |
Dyrcona |
yeah, bug fix tests should be easier than new features, unless the feature is really simple. |
| 16:00 |
abneiman |
because with features, it's not as simple as "do A and get B" - which is why we (Equinox) try to include documentation and tech ref docs with new features, along with extensive commit messages |
| 16:01 |
abneiman |
but, if you all would rather us put out more formal test plans, I can work on that as well |
| 16:01 |
|
rlefaive joined #evergreen |
| 16:01 |
abneiman |
however, we are at the top of the hour so maybe "test plans for big features" could be a future topic |
| 16:02 |
sandbergja |
yeah, that might be where it gets trickier |
| 16:02 |
dluch |
+1 |
| 16:03 |
redavis |
also +1 |
| 16:03 |
abneiman |
#action discussion item for next meeting: test plans for big features |
| 16:03 |
abneiman |
that even might be a worthy hackaway topic |
| 16:03 |
abneiman |
anyway. |
| 16:04 |
abneiman |
anything else to discuss? Anything that I forgot? Any parting words of wisdom? |
| 16:04 |
redavis |
stay hydrated |
| 16:04 |
eeevil |
never start a land war in ... oh, nevermind |
| 16:04 |
abneiman |
#agree we're all gonna stay hydrated |
| 08:55 |
|
Dyrcona joined #evergreen |
| 10:03 |
|
dguarrac joined #evergreen |
| 10:45 |
|
Christineb joined #evergreen |
| 10:54 |
Dyrcona |
Yuck. Tests are failing... |
| 11:56 |
|
jihpringle joined #evergreen |
| 12:20 |
|
collum joined #evergreen |
| 14:22 |
Dyrcona |
The test failures are consistent. I guess I'll have to check on plain old master on a supported distro and Pg version.... I'm using Ubuntu 24 and Pg 16. |
| 15:15 |
Dyrcona |
So, another vm running Ubuntu 24.04 with the same code installed from git rather than a tarball, the live tests so far seem to be working. I wonder if the issue is the tarball or something peculiar to the vm... |
| 15:16 |
Dyrcona |
The other difference is the successful vm runs PG 16 itself, and the other talks to Pg 16 running on a separate server, but that should not matter. |
| 15:21 |
Dyrcona |
Yeah. all tests pass when it is installed from git. I guess I'll check the tarball for anomalies... |
| 15:27 |
Dyrcona |
ok. found an apache thing that might affect the cover uploader. |
| 15:37 |
Dyrcona |
Yeah. That fixed the cover uploader test, but live_t/03-overdue_circ.t, live_t/04-overdue_with_closed_dates.t, and live_t/05-pay_bills.t still fail. |
| 15:41 |
Dyrcona |
Looks like there's an insert error in the database. I'm clearing logs and rebuilding the db. |
| 15:56 |
Dyrcona |
Hm... diff -R ~/Evergreen ~/release/Evergreen-ILS-3.14.0/ doesn't show any significant differences... Nothing that I wouldn't expect. |
| 15:59 |
Dyrcona |
That should be a lowercase '-r', not '-R'. I should have copy/pasted. |
| 16:09 |
Dyrcona |
So, it is something in this VM's environment because the tests fail when installed from git, too. |
| 16:43 |
Dyrcona |
So... Install Pg 16 on the vm where the tests were failing and configure it to use that one instead of the db server, and the tests pass. That's it. That's all I changed. |
| 16:45 |
Dyrcona |
That *might* help explain some billing bugs, maybe.... If the tests consistently fail on a remote database. |
| 16:49 |
Dyrcona |
Except this one decided to fail: live_t/18-lp1592891_sip_standing_penalties.t. It was succeeding before. |
| 16:49 |
* Dyrcona |
calls it a day/week. |
| 15:06 |
sandbergja |
that's farther than we've gotten hahaha. Unsurprisingly, we have spent a lot of time on the ownership chapter |
| 15:07 |
Dyrcona |
yeah. if [ ! -f ../dojo.tgz ].... I just have to rename it. |
| 15:08 |
Dyrcona |
Yeah, the ownership seems tricky.. Just pass everything as a reference is my take away. :) |
| 15:08 |
sandbergja |
heh, seriously! |
| 15:09 |
sandbergja |
we did try an experiment this week in one of our rails apps, we rewrote a method in Rust, and then used ffi to let Ruby find the compiled dynamic library. All of our ruby tests still passed, it was pretty cool. Lots of glue code though :-( |
| 15:09 |
berick |
neat! |
| 15:10 |
Dyrcona |
Yeah. Sound neat. I was think of doing crazy stuff at some point like hooking up the LibreOffice API. |
| 15:10 |
sandbergja |
ooh, cool |
| 15:43 |
Dyrcona |
I suspect that this has more to do with using the latest main over anything sandbergja changed. |
| 15:43 |
Dyrcona |
Bleh: fatal: tag 'rel_3_14_0' already exists |
| 15:44 |
Dyrcona |
I'll have to start over and delete the tag. |
| 15:45 |
sandbergja |
Dyrcona: was that angular error from `ng build` or the tests? |
| 15:46 |
Dyrcona |
sandbergja: I'm not sure. Let me check the scroll back. |
| 15:46 |
sandbergja |
hmmmm... I wonder if it would be good to have a "clobber" option for the git tag, in case you have to re-run it |
| 15:46 |
Dyrcona |
The warnings and errors come after "Browser application bundle generation complete." |
| 15:47 |
sandbergja |
ah gotcha |
| 15:48 |
Dyrcona |
It doesn't say it is running tests, yet. I could try a manual build from git later to see what happens. |
| 15:48 |
Dyrcona |
I'm going to git clean -xfd to make sure. I think I did that earlier. |
| 15:48 |
Bmagic |
Dyrcona berick: I solved by downloading the file manually via web browser (theory is that the browser is more error tolerante compared to wget) - then put the resulting download file in ../release/dojo..... (exact path is mentinoed in the build bash script) - and if the file exists, then it doesn't waste time wgeting a fresh copy |
| 15:49 |
Dyrcona |
Bmagic: I just did more or less the same, but used rsync to pull both dojo.tgz from the server and compare them on my laptop before sending one to the vm where I'm playing around. |
| 08:29 |
|
mmorgan joined #evergreen |
| 09:01 |
|
dguarrac joined #evergreen |
| 09:23 |
|
Dyrcona joined #evergreen |
| 09:24 |
Dyrcona |
Why is it that something tested in production over a week ago and worked, doesn't work when I actually want to use it? |
| 09:31 |
Dyrcona |
OK. It IS working. The first thing it tried to do ended up being invalid as far as the new process is concerned. |
| 09:31 |
Dyrcona |
The a/t event is not invalid, but it doesn't meet other criteria in the script. |
| 10:00 |
|
kmlussier joined #evergreen |
| 15:35 |
Bmagic |
with the understanding that we will have a follow-up LP to update the bits for ValKey when that's possible |
| 15:35 |
berick |
the bigger qestion for me is whether the functionality is complete for the various use cases |
| 15:36 |
berick |
which is to some extent aimed at the Equinox folks |
| 15:36 |
Dyrcona |
I've been using it since October on a test instance and haven't noticed anything that doesn't work. |
| 15:36 |
Bmagic |
We have it running on production, for a small library. Working just fine. Though, I'd feel more confident if it were on production for a larger library/consortium |
| 15:37 |
berick |
Bmagic: i'm deploying it as soon as it's merged to opensrf main |
| 15:37 |
berick |
(part of why i'm asking now, want to get going on it) |
| 15:43 |
csharp_ |
the thin ice we're skating on held! (this is fine dog) |
| 15:43 |
* kmlussier |
is hoping reddis isn't quite so painful. |
| 15:43 |
Dyrcona |
jeff csharp_: Yeah, that was my suggestion about the numbering. |
| 15:43 |
Bmagic |
We have a few systems adopting 3.13 over the next few months, I think we can give redis a whirl at the same time. I'd like to see it up and running in a larger environment as proof. I don't think any test environment can do what a production environment does |
| 15:44 |
Dyrcona |
kmlussier: I'm sorry, didn't mean to make light of it. All software is some kind of pain to use. |
| 15:44 |
Dyrcona |
berick has done a great job making the Redis integration just work. Very little configuration required. |
| 15:44 |
Bmagic |
agreed berick++ |
| 16:03 |
Bmagic |
terranm: looks good for me |
| 16:04 |
redavis |
terranm, perfect |
| 16:04 |
sleary |
terranm++ |
| 16:04 |
terranm |
Maybe we'll have the new circ/patron interfaces to test then? |
| 16:04 |
LindaJansova |
terranm++ |
| 16:04 |
redavis |
terranm++ |
| 16:04 |
Bmagic |
terranm++ |
| 10:31 |
|
kworstell-isl joined #evergreen |
| 10:41 |
|
kworstell-isl joined #evergreen |
| 11:25 |
|
Christineb joined #evergreen |
| 12:43 |
mantis |
When manually testing hold expiring soon notices, I have a test set up so that the hold that is captured has a shelf expiration two days from now, but when I run a script, nothing runs. Not sure if anyone has any ideas or tried testing this notice before. |
| 12:52 |
berick |
mantis: we use it w/ delay = '-2 days' and max_delay = '-1 day' |
| 12:53 |
mantis |
ah ok |
| 12:53 |
mantis |
I have a max delay of 2 days |
| 12:54 |
Dyrcona |
Negative for before, positive for after. |
| 12:54 |
eeevil |
mantis: think of delay and max_delay as the age of the timestamp in the field pointed at by delay_field (in fact, it's exactly that!) |
| 12:54 |
eeevil |
as in, the output of the age() function in the db |
| 12:55 |
mantis |
eevil: I also thought had to do something with the timestamp, but testing wasn't as fruitful |
| 12:55 |
mantis |
and when you edit the hold dates in the regular circ module, it doesn't give a timestamp option |
| 12:55 |
mantis |
berick: I gave that a shot and no dice |
| 12:56 |
mantis |
my shelf expire time is set to 6-12-2024 00:00:00-04 |
| 13:01 |
Dyrcona |
mantish: action_trigger.event_hook specifies a "core_type" for the event. This is the main IDL class used by the event. action_trigger.event_definition specifies a delay_field, delay, and max_delay. |
| 13:01 |
Dyrcona |
The delay and max_delay (if present) are added to the value of the delay_field of the object being processed to determine if an event should be generated for that object. |
| 13:03 |
Dyrcona |
To process things from the past, i.e. a 30-day overdue event, you would use positive values in delay and max_delay. For future things, like hold expires in 2 days, use negative values. So a delay of '-2 days' and a max_delay of '-1 days' would get everything between tomorrow and two days from now. |
| 13:11 |
mantis |
eevil++ |
| 13:11 |
mantis |
Dyrcona++ |
| 13:11 |
Dyrcona |
I'd check the action_trigger_filers.json in /openils/conf, or if you're using custom filters, make sure that file is there. |
| 13:11 |
* Dyrcona |
often forgets the filters when testing triggers. |
| 13:15 |
Rogan |
This is also sent out on the general dev lists but details for the 2024 Hack-A-Way are now available: https://wiki.evergreen-ils.org/doku.php?id=hack-a-way:hack-a-way-2024 |
| 13:48 |
|
terranm joined #evergreen |
| 13:54 |
terranm |
Claiming 1419 |
| 12:03 |
|
Christineb joined #evergreen |
| 12:13 |
Dyrcona |
This is why I kept putting this off: there are a couple of places this could be fixed, and then there's the temptation to rip it up and implement something quite a bit different.... |
| 12:21 |
Dyrcona |
I suppose I could build a copy of the provider/account list and use grep to prevent duplicates. |
| 12:29 |
Dyrcona |
That works in my simple test. The list went from 180 to 29. |
| 12:47 |
Dyrcona |
heh. I typoed "Depulicate" as "Depuplicate" and my spell check suggested "Depopulate" with also works. :) |
| 12:48 |
Dyrcona |
OMG!!! "Deduplicate" not "Depulicate.".... |
| 12:48 |
Dyrcona |
@blame finger |
| 12:48 |
pinesol |
Dyrcona: finger is why we can never have nice things! |
| 12:48 |
berick |
@band add The Depopulaters |
| 12:48 |
pinesol |
berick: Band 'The Depopulaters' added to list |
| 12:49 |
Dyrcona |
berick: I ended up adding a loop in O::A::Acq::EDI::retreive_core to remove duplicate accounts/in_dir combinations from the list. I can test it in a minute. I'll put a link to the commit once I've pushed it to the working repo. |
| 12:58 |
|
jvwoolf joined #evergreen |
| 13:00 |
jeffdavis |
I think "depulication" would technically be flea removal. |
| 13:09 |
Dyrcona |
jeffdavis++ |
| 16:31 |
Bmagic |
completely deleting the value |
| 16:31 |
abneiman |
yes |
| 16:32 |
berick |
not really a shortcut, but an inability to move the curser to the character you want to edit |
| 16:32 |
Bmagic |
WTF, it didn't do that in a previous test |
| 16:32 |
abneiman |
anyway I think we have a fix |
| 16:32 |
abneiman |
stand by |
| 16:34 |
sleary |
I'm seeing the right arrow issue, but I have no problem saving an edited subfield. |
| 16:36 |
berick |
yeah, other fields save OK for me too |
| 16:36 |
sleary |
... yeah, that's bad |
| 16:36 |
berick |
Bmagic: same :) |
| 16:37 |
Bmagic |
interesting. What a nuance. Thinking back to when I tested that branch, I edited marc records like crazy but I don't think I interacted with a larger subfield like that |
| 16:37 |
abneiman |
I'm not seeing it on our internal 3.13-rc, even in multi line fields |
| 16:37 |
abneiman |
weird |
| 16:37 |
Bmagic |
weird indeed. Imma install from git and see |
| 17:11 |
|
jihpringle joined #evergreen |
| 17:15 |
berick |
sleary: yes |
| 17:19 |
* berick |
sees the working branch |
| 17:20 |
sleary |
berick I think we have a fix, but eeevil just found a bunch of missing libraries on my dev server that are causing other problems |
| 17:20 |
sleary |
testing it on a different server now |
| 17:20 |
eeevil |
deploying to butternut for testing now... |
| 17:22 |
berick |
seems partly fixed. editing existing values is better. creating new ones is still having issues. |
| 17:24 |
|
kworstell-isl joined #evergreen |
| 17:24 |
eeevil |
berick: you mean the arrow key issue, or something else? |
| 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 |
| 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++ |
