| Time |
Nick |
Message |
| 00:12 |
|
Keith__isl joined #evergreen |
| 00:12 |
|
alynn26_away joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:14 |
|
mantis joined #evergreen |
| 07:34 |
|
tlittle joined #evergreen |
| 07:34 |
|
collum joined #evergreen |
| 08:13 |
|
rfrasur joined #evergreen |
| 08:31 |
|
Dyrcona joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:41 |
|
dguarrac joined #evergreen |
| 08:51 |
|
dguarrac_ joined #evergreen |
| 09:45 |
|
mmorgan1 joined #evergreen |
| 10:28 |
|
jvwoolf joined #evergreen |
| 10:35 |
|
jvwoolf1 joined #evergreen |
| 10:47 |
|
nfBurton joined #evergreen |
| 10:56 |
|
dguarrac joined #evergreen |
| 11:05 |
|
jvwoolf joined #evergreen |
| 11:11 |
|
nfBurton28 joined #evergreen |
| 11:11 |
|
nfBurton88 joined #evergreen |
| 11:30 |
Dyrcona |
I've added settings for the backend admin user and org unit in the Quipu Ecard code and modified it to use them. I've tested what happens with some similar code if the settings are not set. It fails, of course, and the message is: "Can't call method "id" on an undefined value." |
| 11:30 |
Dyrcona |
I see 2 ways to deal with this, just return if either or both settings are not found, or fallback to using the already retrieved vendor user and org unit 1. |
| 11:31 |
Dyrcona |
csharp_ || berick ^^ |
| 11:33 |
Dyrcona |
I'm leaning toward the fallback mode. Does anyone have an opinions either way? I know it's hard to say without context. |
| 11:47 |
|
mmorgan1 joined #evergreen |
| 11:56 |
|
nfBurton28 joined #evergreen |
| 11:58 |
|
jihpringle joined #evergreen |
| 12:10 |
|
jvwoolf joined #evergreen |
| 12:21 |
|
jvwoolf joined #evergreen |
| 13:04 |
Dyrcona |
Here's a new one on me: One of our catalogers tried emailing from a vandelay queue and the email went to root localhost. Turns out the mail address on the cataloger's account was not set. Even after setting the email in actor.usr, the next email still went to rootloclalhost. |
| 13:06 |
Dyrcona |
Yes, the cataloger is the owner of the queues. |
| 13:08 |
Dyrcona |
The environment looks good, too. |
| 13:14 |
Dyrcona |
Ah ha! I think it is a bug in the template. |
| 13:15 |
Dyrcona |
Eh, no. False alarm. |
| 13:16 |
rfrasur |
I am following this thread o' Dyrcona. |
| 13:17 |
Dyrcona |
It doesn't appear to be going anywhere. I think the a/t is getting cached data for the user from memcached or something, but I don't really know right now. |
| 13:20 |
Dyrcona |
This happens in the template: [%- SET user = target.0.record.queue.owner -%] |
| 13:20 |
Dyrcona |
To: [%- params.recipient_email || user.email || 'rootlocalhost' %] |
| 13:21 |
Dyrcona |
record, record.queue, and record.queue.owner are in the action_trigger.environment for this event definition. |
| 13:27 |
|
collum joined #evergreen |
| 13:31 |
Dyrcona |
Yeah, no apparent cause for the email going to rootlocalhost, even though the staff account has a valid email set. The first occurrence yesterday, there was no email, but I set the email through the staff client before they tried again today. |
| 13:35 |
mmorgan |
Dyrcona: Is this the "Email Output for Queued Bib Records" definition? |
| 13:37 |
Dyrcona |
mmorgan: Yes it is. |
| 13:37 |
Dyrcona |
Do you know something about it? |
| 13:40 |
mmorgan |
Not until you asked. I just went to look at event_output and see 3 out of the 4 from that definition have To: rootlocalhost |
| 13:40 |
mmorgan |
Doesn't look like it gets used much in our system - maybe because the emails don't arrive :) |
| 13:42 |
Dyrcona |
mmorgan: Yesterday was the first time that I'm aware anyone here tried to use it. |
| 13:49 |
Dyrcona |
We have aliases configured so that emails to rootlocalhost end up going to a list read by myself and our systems staff. |
| 13:55 |
Dyrcona |
mmorgan: Would you be able to confirm whether or not the owners of the queues associated with your events have an email address set or not? |
| 14:12 |
* mmorgan |
will have a look |
| 14:16 |
Dyrcona |
mmorgan: if it helps: https://pastebin.com/5sRBfpRK |
| 14:23 |
mmorgan |
Dyrcona: Thanks for the query :). But I get no rows returned. I'm thinking the queues no longer exist. |
| 14:25 |
Dyrcona |
Could be. |
| 14:25 |
Dyrcona |
mmorgan++ Thanks for looking. |
| 14:26 |
Dyrcona |
I also changed the query so it doesn't depend on event definition ids. |
| 14:27 |
mmorgan |
Still no rows :-( |
| 14:28 |
Dyrcona |
While on the topic of action_trigger: berick | csharp_ There's code in the Ecard module to create action_trigger.events, but no database code to add the definitions. Is that an oversigt? |
| 14:29 |
Dyrcona |
mmorgan: Yeah, if the previous query returned nothing, then this one should, too. |
| 14:30 |
berick |
Dyrcona: i manage sql differently localy, so i didn't include any sql in my source branch. |
| 14:30 |
Dyrcona |
berick: All right, but we'll want something for the upgrade script or are those events KCLS-specific? |
| 14:31 |
berick |
Dyrcona: no, we'll want something for the upgrade script |
| 14:32 |
Dyrcona |
berick: If you could send it to me when you get a chance, that would be great. berick++ |
| 14:33 |
berick |
Dyrcona: it's a little funky, because we send print notices for ecards so the user is required to be at the address entered so they can enter the verification code |
| 14:33 |
berick |
EG does not have a base "print notice" setup |
| 14:34 |
berick |
well, i guess there are some examples for unique stuff in there |
| 14:34 |
berick |
s/unique/Unique Mgmt/ |
| 14:35 |
Dyrcona |
OK. That also sounds like a KCLS work flow to me. Would an email work for a generic event? |
| 14:35 |
berick |
Dyrcona: it would, but undermines the security |
| 14:35 |
berick |
e.g. i could sign up for an ecard at your library |
| 14:36 |
berick |
since you have no way of verifying where I physically reside |
| 14:36 |
Dyrcona |
Yes, but isn't Quipu supposed to verify the address? |
| 14:36 |
berick |
they do verify the address, but I could easily find a name and address in your service area |
| 14:37 |
berick |
if you're not worried about that level of hijinks, then an email would work fine |
| 14:38 |
Dyrcona |
I don't think anyone here has discussed sending something in the mail, and I think that would be a non-starter. |
| 14:39 |
Dyrcona |
I do see your point. |
| 14:40 |
Dyrcona |
If you could still send me what you have, I'd appreciate it. Make any redactions you feel necessary. Thanks, again! |
| 14:42 |
berick |
sure, but our 3rd-party notice generation is nothing like stock EG. |
| 14:42 |
berick |
my event def https://gist.github.com/berick/12981342354efa7601b250982189c9f4 |
| 14:42 |
berick |
using this code https://github.com/berick/evergreen-xml-notices |
| 14:42 |
Dyrcona |
Sure, I know. |
| 14:44 |
Dyrcona |
Thanks! |
| 15:19 |
|
jihpringle joined #evergreen |
| 15:24 |
Dyrcona |
It's easy to get carried away when it comes to adding new settings. :) |
| 15:28 |
|
mmorgan1 joined #evergreen |
| 15:29 |
Dyrcona |
This API name always makes me smile: open-ils.storage.actor.user.crazy_search |
| 15:31 |
mmorgan |
:) |
| 15:42 |
|
mmorgan1 joined #evergreen |
| 16:04 |
|
jvwoolf left #evergreen |
| 16:06 |
jeff |
this goes back to "verifying the person exists" vs "verifying you are the person in question" :-) |
| 16:16 |
Dyrcona |
jeff: Uh-huh. |
| 16:17 |
Dyrcona |
I'm not convinced that we can add a print event as a standard part of Evergreen at this point. |
| 17:05 |
|
nfBurton joined #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:39 |
|
jihpringle joined #evergreen |
