| Time |
Nick |
Message |
| 05:11 |
|
eby joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:25 |
|
jeffdavis joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:33 |
|
mantis joined #evergreen |
| 08:36 |
|
Stompro joined #evergreen |
| 08:38 |
|
Stompro joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 09:04 |
|
jvwoolf joined #evergreen |
| 09:12 |
|
jvwoolf left #evergreen |
| 09:21 |
|
Dyrcona joined #evergreen |
| 09:28 |
Dyrcona |
mmorgan: If you look at this spreadsheet, https://docs.google.com/spreadsheets/d/1ogorilx8KWo2vqQdLYn_qeQsU_DaQSFrn-1MCOykd8A/edit?usp=sharing, it looks like Pg 12 is where located URI performance really takes a hit. |
| 09:30 |
mmorgan |
Dyrcona: Indeed! Interesting. |
| 09:30 |
mmorgan |
Dyrcona++ |
| 09:30 |
Dyrcona |
That's only 1 run each. To be truly scientific, it should be repeated thousands of times and the results averaged, but "Ain't nobody got time for that." |
| 09:35 |
Dyrcona |
I'm going to upload the plprofiler output, but they're HTML files so you can't just view them using drive. I think they'd have to be downloaded and then opened in the browser. |
| 09:43 |
|
rfrasur joined #evergreen |
| 09:58 |
|
jvwoolf1 joined #evergreen |
| 10:06 |
Bmagic |
Does the action trigger code skip inserting a row into action_trigger.event when the configured opt_in_setting is missing for the patron? |
| 10:09 |
Dyrcona |
Bmagic: Well, was the event created? |
| 10:09 |
Bmagic |
I' |
| 10:10 |
Bmagic |
m trying to skip the creation. I think the process-hooks phase |
| 10:10 |
Dyrcona |
Well, I suppose it depends on which call is used to create the events, but it loos like the answer is "Yes." |
| 10:11 |
Dyrcona |
There is a call that will ignore the opt-in setting, but I don't think it is used. You'd have to write something to use it. |
| 10:11 |
Dyrcona |
open-ils.trigger.event.autocreate.ignore_opt_in is a thing that exists. |
| 10:13 |
berick |
Bmagic: yes, it skips creating the events |
| 10:13 |
Bmagic |
Dyrcona++ berick++ |
| 10:14 |
Bmagic |
saves me from having to write a custom trigger json filter |
| 10:18 |
* Bmagic |
wishes it were opt_out instead of opt_in, because it's a smaller dataset for those I want removed rather than included |
| 10:18 |
Bmagic |
maybe I will go with the trigger json filter |
| 10:19 |
* mmorgan |
was going to suggest that the filter might be better in that case :) |
| 10:20 |
Dyrcona |
I suppose a filter would save on processing time. I'm not totally sure, though. |
| 10:21 |
mmorgan |
If the opt_in is not truly based on patron preference, then there'd be some maintenance of those user settings. |
| 10:22 |
Dyrcona |
I'm imagining the case as only a handful of patrons have the setting while the majority do not even have it in actor.usr_setting. Is that correct, Bmagic? |
| 10:24 |
Bmagic |
We have 2.5m patrons, and we don't want 450k of them to be included for these expiration notices. |
| 10:24 |
Bmagic |
so, if I go with the opt_in_setting option, I would be inserting the difference for the "good" patrons into actor.usr_setting, and then yes, we'd need a mechanism to continue to do that |
| 10:25 |
mmorgan |
Bmagic: What identifies the "good" patrons? |
| 10:25 |
Dyrcona |
Is there some way other than opt_in that you could differentiate the patrons? If so, that would be better for a filter, I'd think. |
| 10:26 |
Bmagic |
there is a special project that creates a set of student patrons, who all have the same expiration date. They are, unfortunately, getting gathered up in the expiration notices. |
| 10:26 |
Dyrcona |
I'm not a fan of adding user settings, particularly when the patron can change them and you don't want them to change them. |
| 10:26 |
Bmagic |
yeah, there is a value in ident_value that we can respect. I think the json filter is best |
| 10:27 |
Dyrcona |
Coincidentally, we're discussing adding opt in settings for many of our notices, which ones, etc. |
| 10:27 |
mmorgan |
We also don't send expiration notices to student patrons, we filter them out based on patron profile. |
| 10:28 |
Bmagic |
mmorgan: using custom json filter? |
| 10:28 |
Dyrcona |
I don't think we filter ours. I'll take a look. |
| 10:28 |
mmorgan |
Bmagic: Yes, custom json filter. |
| 10:28 |
Bmagic |
yeah, it's looking more and more like that's the ticket |
| 10:29 |
Dyrcona |
We use the default filter for au.expired. |
| 10:29 |
Bmagic |
mmorgan, mind sharing the json? |
| 10:29 |
Dyrcona |
I agree with a custom filter and not an opt in setting. |
| 10:30 |
mmorgan |
Bmagic: Just a sec, looking. |
| 10:30 |
Bmagic |
ty |
| 10:33 |
pastebot |
"mmorgan" at 168.25.130.30 pasted "Expiration filter" (11 lines) at http://paste.evergreen-ils.org/14425 |
| 10:33 |
mmorgan |
Bmagic: ^^ |
| 10:34 |
Bmagic |
mmorgan++ |
| 10:35 |
Bmagic |
its "-not" for what I want I think |
| 10:36 |
mmorgan |
Bmagic: Yes. We specify the profiles that are getting the notices. |
| 10:37 |
Bmagic |
something like "-and" : ["ident_value" : {"!=": "student"}] (I know that's wrong) |
| 10:39 |
Dyrcona |
Bmagic: ident_type = 2 is "College ID" is that set on the patrons you want to skip? |
| 10:39 |
Bmagic |
There is a special string for the value. The type is "other" |
| 10:40 |
Bmagic |
we want to include patrons that DO NOT have this value |
| 10:40 |
Dyrcona |
Anyway, just "ident_value" : { "!=" : "student" } should work. And is assumed. |
| 10:43 |
Bmagic |
riffing off of mmorgan's, I came up with: (paste incoming) |
| 10:44 |
pastebot |
"Bmagic" at 168.25.130.30 pasted "json filter" (11 lines) at http://paste.evergreen-ils.org/14426 |
| 10:46 |
pastebot |
"Dyrcona" at 168.25.130.30 pasted "This should also work" (11 lines) at http://paste.evergreen-ils.org/14427 |
| 10:46 |
Dyrcona |
Bmagic ^^ |
| 10:46 |
Bmagic |
can I get a sanity check? I've tried my hand at these JSON filters several times and it's tricky to say the least. And testing in dev is "fun" |
| 10:46 |
Bmagic |
Dyrcona: I like that better. I was thinking that I could drop the redundant "and" - like you said, it was assumed |
| 10:47 |
* mmorgan |
always has to carefully test before letting them loose. |
| 10:47 |
Dyrcona |
"and" is useful when you're doing more complicated things, like nesting with "or" for example. |
| 10:48 |
Bmagic |
gotcha |
| 10:48 |
mmorgan |
I usually change the reactor for the a_t template to ProcessTemplate instead of SendEmail, then check the db for the output. That way no emails are generated. |
| 10:49 |
Dyrcona |
Just running --process-hooks should be enough to see if the filter works. You can compare the created event targets to what you expect to get. |
| 10:50 |
Dyrcona |
My dev machine can't send email, so that helps when testing triggers. |
| 10:50 |
mmorgan |
Dyrcona: Good idea!! |
| 10:51 |
Dyrcona |
Also, you can update all the email addresses to go to yourself if you don't mind getting spammed. :) |
| 10:52 |
* mmorgan |
has done that, too. But only once :) |
| 12:11 |
Bmagic |
haha, yeah, I think I would prefer to null the email address field and query aciton_trigger.event |
| 12:30 |
|
jihpringle joined #evergreen |
| 12:42 |
Bmagic |
Dyrcona: your JSON syntax is sound. Tested on dev with some tricky staging for a patron within range and with the value. Proved that the filter will include the patron when that value is missing, but exclude when it's present |
| 12:42 |
|
jihpringle joined #evergreen |
| 13:16 |
Dyrcona |
Bmagic: I'd make sure to check it with patrons that have ident_value: null. |
| 13:17 |
Dyrcona |
I think it should work as-is, but it would be good to make sure. |
| 13:25 |
Dyrcona |
Actually, I don't think it will get those that are null. You'll need something more complicated. |
| 13:50 |
pastebot |
"Dyrcona" at 168.25.130.30 pasted "Bmagic: You really want something like this:" (16 lines) at http://paste.evergreen-ils.org/14428 |
| 13:53 |
Dyrcona |
Interesting... One can also delete the "-and" : from that query and it still works. I think that's because [ and ] are replaced by ( and ). |
| 13:53 |
Dyrcona |
It has been a while since I fiddled with raw json queries. |
| 13:54 |
Dyrcona |
Grr. I may have mispoke. I just realized that I modified the wrong file. :( |
| 13:55 |
Dyrcona |
Forget that. It's a query error without the and. |
| 13:55 |
Dyrcona |
Can you tell it's Friday? |
| 14:21 |
csharp_ |
@eightball is it Friday? |
| 14:21 |
pinesol |
csharp_: The answer is a resounding no. |
| 14:30 |
alynn26 |
pinesol lies |
| 14:30 |
pinesol |
alynn26: MARC still isn't dead yet, alas |
| 14:33 |
* mmorgan |
covers ears in denial of it not being Friday! |
| 15:31 |
Dyrcona |
@eightball Will it blend? |
| 15:31 |
pinesol |
Dyrcona: You know the answer better than I. |
| 15:36 |
Dyrcona |
csharp_ | berick: There's something I don't understand about permissions in the Quipu branch, but 3:30 on a Friday may not be the correct time to start that discussion. |
| 15:38 |
csharp_ |
Dyrcona: correct :-) |
| 15:39 |
Dyrcona |
To make it short, I had to give both accounts the same permissions. I thought only the permission of the account that makes the temp session would matter. |
| 15:39 |
Dyrcona |
Maybe I broke something? |
| 15:45 |
csharp_ |
I'm a bit rusty on the code, but looking right now, we just use the authtoken generated by the login_vendor sub - what's the other account? |
| 15:48 |
Dyrcona |
So, the code verifies the vendor usrname and password, then it makes a temp session with a different usrname. I had to give the vendor the same permissions as the latter account. |
| 15:49 |
Dyrcona |
Oh! |
| 15:50 |
Dyrcona |
I made another mistake. My code uses a library setting, not a hard-coded value, and I apparently forgot to set the library setting. |
| 15:50 |
Dyrcona |
BTW, once I'm done, we'll be closer to something that is more generically useful, but I still don't think the code will be ready for inclusion in mainline Evergreen. It will need more work and documentation. |
| 15:52 |
Dyrcona |
csharp_++ |
| 15:53 |
Dyrcona |
For playing rubber ducky. |
| 15:54 |
Dyrcona |
Reason giving the vendor account the same permissions worked is the code falls back to the vendor account if it fails to look up the OU setting. |
| 15:54 |
Dyrcona |
It has been one of those Fridays, but at least it's a long weekend for me. |
| 16:06 |
Bmagic |
Dyrcona: oh right, you're right. Testing |
| 16:26 |
|
jvwoolf1 left #evergreen |
| 16:30 |
Bmagic |
Dyrcona: turns out, the original json worked for null values |
| 16:33 |
Dyrcona |
Bmagic: In my testing of a json query to look up patrons, it didn't work. That's a little different from using a filter, though. |
| 16:36 |
Bmagic |
sorry, bad test. I forgot I left my json filter file without the ident_value filter from this morning's test. Fixed that, and now, it in fact, does not turn up non-null ident_value patrons. So yeah, it needs the more complex json |
| 16:37 |
Bmagic |
Another side note: action_trigger_runner is making duplicate action_trigger.event rows when --process-hooks is ran back to back (not run-pending) |
| 16:37 |
Bmagic |
I thought it checked it's own table for the same target and event_def |
| 16:42 |
Dyrcona |
Bmagic: It should check, but it may be looking for something else, too, like one of the dates. I'd have to check the code again, and of course, I'm in the middle of something else. |
| 16:42 |
Bmagic |
no biggy, thought it was worth a mention. Dyrcona++ |
| 17:00 |
Dyrcona |
Bmagic: Is there a repeat_delay on the au.expired event def that you're using? |
| 17:01 |
Bmagic |
oh right, that's the issue |
| 17:01 |
Bmagic |
It's not been setup on 100% of the triggers |
| 17:02 |
Bmagic |
I take that back, it is setup on 100% of au.expired, but maybe the delay needs to be negative days instead of positive days for a trigger that is "courtesy" in nature |
| 17:03 |
Dyrcona |
The delay should be negative, yes. |
| 17:04 |
Bmagic |
that cant be right either because it should be comparing the time against action_trigger.event.run_time |
| 17:05 |
Dyrcona |
I'd have to actually play with it some, and it's after 5:00 PM here on a Friday, so.... :) |
| 17:05 |
Bmagic |
yeah, lol, you shouldn't be "here" |
| 17:05 |
Bmagic |
you have a good weekend! |
| 17:05 |
Bmagic |
and everyone else too! |
| 17:06 |
Bmagic |
and remember to not work on Monday |
| 17:06 |
Dyrcona |
Yeah, have a great weekend, everybody! |
| 17:09 |
|
mmorgan left #evergreen |
| 17:46 |
|
jvwoolf joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:03 |
|
jvwoolf left #evergreen |
| 20:00 |
|
jweston joined #evergreen |
| 20:00 |
|
Stompro joined #evergreen |
| 20:01 |
|
akilsdonk joined #evergreen |
| 20:02 |
|
StomproJ joined #evergreen |
| 21:44 |
|
Stompro joined #evergreen |
