Time |
Nick |
Message |
01:14 |
|
abneiman joined #evergreen |
05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
07:16 |
|
rjackson_isl joined #evergreen |
08:01 |
|
collum joined #evergreen |
08:46 |
|
mmorgan joined #evergreen |
08:50 |
|
collum_ joined #evergreen |
09:14 |
|
yboston joined #evergreen |
09:16 |
|
agoben joined #evergreen |
09:27 |
tsbere |
You know it is time to re-think your query when it ran for 16+ hours with no signs of stopping. |
09:27 |
* tsbere |
suspects he needs to add some indexes |
09:30 |
|
kmlussier joined #evergreen |
09:53 |
|
maryj joined #evergreen |
10:00 |
jeff |
ah, the old classics never die: ``1/10/17 Dog Training book had corner chewed at check out.'' |
10:02 |
* mmorgan |
noticed a long overdue copy of "potty train your child in one day" yesterday. |
10:04 |
|
Dyrcona joined #evergreen |
10:04 |
|
mmorgan1 joined #evergreen |
10:15 |
csharp |
jeff++ mmorgan++ |
10:18 |
berick |
mmorgan1: it doesn't way *which* day |
10:18 |
berick |
s/way/say/ |
10:21 |
berick |
potty train your child on the last light of Durin's day |
10:24 |
Dyrcona |
OK... |
10:24 |
Dyrcona |
:) |
10:27 |
Dyrcona |
berick: Max Keiser says he's going to run for Congress in North Carolina's sixth district during the midterm election. |
10:27 |
Dyrcona |
Just thought you might like to know that. :) |
10:32 |
berick |
crazy |
10:32 |
|
StomproJ joined #evergreen |
10:42 |
jeff |
okay, success in using window functions (LEAD, in this case) to report on patron alert message changes. |
10:45 |
berick |
jeff: is there a LP bug for the "hold notices using old emails, etc." stuff? |
10:49 |
jeff |
berick: i'm drawing a blank. are you talking about my desire to eliminate per-hold notification targets like phone and sms notify? |
10:50 |
berick |
jeff: yes, you deciphered my vagueness ;) |
10:50 |
jeff |
no, no LP that I'm aware of. |
10:50 |
berick |
k, not finding one either |
10:50 |
berick |
thanks |
10:50 |
jeff |
i'm not sure if "rip it out" has enough support. |
10:52 |
jeff |
"prompt staff to auto-update outstanding holds" and "configurable option to not ask for (and ignore/override) per-hold targets" have both been tossed around as compromises. |
10:53 |
jeff |
i think people also have stronger opinions on the per-hold booleans vs the per-hold notification targets. in our environment, we've done away with both. |
10:54 |
jeff |
your notification settings at the time that the hold goes available are how you are notified for that hold. |
10:54 |
jeff |
(with one or two theoretical corner cases that i've on my list to hunt down) |
10:55 |
* berick |
tests the tpac, sees that it forces patrons to use the email on the account and provides no way to change the email value |
10:56 |
berick |
that kind of renders the whole feature useless, doesn' it? |
10:56 |
jeff |
berick: because there is no per-hold email string, just a bool for yes/no. |
10:56 |
jeff |
but unlike email, there are per-hold phone_notify and sms_notify (and sms_carrier) settings. |
10:57 |
jeff |
which function as both bool and target, iirc. |
10:57 |
berick |
oh, right... |
10:57 |
berick |
thanks for the reminders, jeff |
10:57 |
jeff |
if there's a value in phone_notify, then you send phone notification to the value present in that field, and if there's a value in sms_notify and sms_carrier, you send notifications there. |
10:58 |
jeff |
but email_notify is just a bool, which means "send email to the address in actor.usr.email" |
10:58 |
berick |
right, ok |
10:59 |
jeff |
all of phone_notify (text), email_notify (bool), sms_notify (text), and sms_carrier(int) are set at hold request time based on a combination of values from actor.usr and actor.usr_setting. |
10:59 |
jeff |
and then staff can change them after that. |
10:59 |
jeff |
i think in stock tpac there isn't a way to change some/all of those per-hold. |
11:00 |
jeff |
in jspac i'm pretty sure there was (though jspac may have pre-dated sms notification options). |
11:02 |
jeff |
shifting gears, now i have a report that can be used to see patron alert message changes in the last X days, which can be useful for all manner of things. |
11:03 |
jeff |
"on X date, user Y at workstation Z changed alert_message from A to B" |
11:03 |
* csharp |
just created a report for staff to see SMS notify hold-ready notices |
11:03 |
|
Christineb joined #evergreen |
11:05 |
csharp |
http://pastebin.com/wP1PKjNr - for anyone who wants to build a template like mine |
11:06 |
* csharp |
gets to work on one for preminders |
11:07 |
jeff |
"preminders"! that was the term. i found myself trying to remember your term for that the other day. |
11:07 |
jeff |
standing in front of a microwave, iirc. |
11:07 |
csharp |
heh |
11:08 |
csharp |
"pre" because we're reminding people to return their items *before*... oh. |
11:16 |
* berick |
always called them predue's |
11:16 |
berick |
i like preminders, though |
11:17 |
csharp |
Lamar Veatch came up with "preminders" iirc |
11:22 |
miker |
re hold notification options, here's my recollection of the reasons behind each: |
11:24 |
miker |
email uses saved value to keep people from emailing things to arbitrary (other) people (worst case reason: harassment; best case reason: force patrons to keep their email up to date) |
11:25 |
miker |
phone allowed per hold so people can place a hold for pickup at a "foreign" library and get a call at a location they'll be at when the hold is captured (at college, on vacation, etc) without changing their account info |
11:25 |
miker |
sms: "it's like a phone call, so do the same as that" ... that's, perhaps, dubious |
11:28 |
JBoyer |
I'd be curious how many people actually use day phone for work and night for home, maybe we'd be better served with many to one phone->user maps where there's a phone type similar to a contact app. System types would be home, work, and mobile, with mobile being "magic" and being used for sms also. Then you only need to choose a carrier once for your account. |
11:28 |
JBoyer |
and choose which phone you want to be notified at when placing a hold. |
11:29 |
JBoyer |
Not saying that's the best way, but it satisfies jeff's (and others) desire to get numbers out of ahr, while still allowing situations like the ones miker mentions. |
11:33 |
miker |
JBoyer: that all sounds reasonable to me |
11:34 |
miker |
re the phone field, remember that was from before smart phones were really a thing, and not everyone had a mobile phone |
11:35 |
JBoyer |
Oh, I know, I'm just saying that they're not likely to be missed. And also how many people library notification calls at work. ;) |
11:36 |
miker |
we are in violent agreement :) |
11:36 |
* Dyrcona |
forwards his work phone to his personal cell phone. |
11:36 |
* JBoyer |
used to. Oh, for the days of VOIP again. :( |
11:36 |
JBoyer |
(current system feels like it's from the 80's.) |
11:37 |
Dyrcona |
Trouble with VOIP is when your Internet is down, your phones are down, too. :) |
11:37 |
Dyrcona |
Though the forwarding might still work depending on where it happens. |
11:37 |
JBoyer |
I've long been of the opinion that if we're talking on the phone one of us has screwed up anyway, so that's really more of a plus. ;) |
11:43 |
kmlussier |
I think the reason behind the per-hold for SMS was different. You may be fine with e-mail notification for most hold, but if it's you need to get immediately or are just looking forward to getting, you may want to get the text message. |
11:43 |
|
khuckins joined #evergreen |
11:46 |
kmlussier |
I don't know that there are serious objections to changing the behavior. I just don't think anyone has queried the community outside of IRC to find out if there are objections. |
11:46 |
Dyrcona |
Yeah, that's been my thought on SMS notification for things that are urgent, like you need it for your term paper or something like that. |
11:48 |
Dyrcona |
It's probably a marginal use case, and most other software doesn't give those kinds of options. |
11:48 |
Dyrcona |
You typically get all of your notifications via txt or email and that's it. |
11:55 |
berick |
sounds like there are 2 issues.. 1. storing potentially stale data (old phone numbers) on holds. 2. storing potentially stale notification preferences, e.g. email=true on the hold, but false in user preferences (or vice versa) |
11:55 |
jeffdavis |
mmorgan1: in bug 1086458 you mentioned seeing an apparent memory leak with patron search in the XUL client. Do you recall if the fix for that bug made the problem go away? |
11:55 |
pinesol_green |
Launchpad bug 1086458 in Evergreen 2.4 "Staff client memory leaks in 2.3 and later" [High,Fix released] https://launchpad.net/bugs/1086458 |
12:02 |
|
brahmina joined #evergreen |
12:02 |
pinesol_green |
[evergreen|blake] LP1659892: Remove page from URL in metarecord navigation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=421bf91> |
12:06 |
kmlussier |
hmmm...that commit has the wrong LP number |
12:06 |
jeffdavis |
note to self: see also bug 1110817 |
12:06 |
pinesol_green |
Launchpad bug 1110817 in Evergreen "staff client patron search results continuously eats memory" [Medium,Incomplete] https://launchpad.net/bugs/1110817 |
12:07 |
jeffdavis |
bah, I keep interrupting people, sorry :/ |
12:08 |
kmlussier |
Actually, no, it's the right LP number. Sorry for the noise. |
12:09 |
kmlussier |
jeffdavis: You're not interrupting anything other than me babbling. |
12:10 |
kmlussier |
At what point do we set up a milestone for 2.12 in Launchpad? |
12:15 |
Dyrcona |
Since you're the RM, I'd say that is mostly up to you. |
12:18 |
kmlussier |
Dyrcona: OK, I wasn't sure if there was a precedence I should be following. |
12:21 |
|
jihpringle joined #evergreen |
12:26 |
|
jvwoolf joined #evergreen |
12:32 |
|
bmills joined #evergreen |
12:38 |
|
mmorgan joined #evergreen |
12:46 |
* mmorgan |
catches up |
12:52 |
mmorgan |
jeffdavis: Hard to say if the fix for 1086458 made the problem go away entirely. Many variables changed - OSs, workstation hardware, etc. Have not done another concise test since, but my current unscientific impression is that there are still some 'memory leak' issues related to patron searches. |
12:54 |
jeffdavis |
mmorgan: understood, thank you |
12:59 |
miker |
csharp: re the desire for "stacked" validators and such from the other day, the module loading logic is built such that if you can toss a perl module anywhere that perl can find it for "use", you can create your own validators (and reactors, etc). So if you created a module called, say, PINES::AT::Validators and in there you had subs (like "sub sms_validate {...}' that pulled in and used stock validators in the order you wanted, and did other |
12:59 |
miker |
validations as well, you could configure A/T to use them. Just add a validator module (via staff client config) for, say, PINES::AT::Validators::sms_validate and make use of it |
12:59 |
miker |
there's no reason for everyone to use the stock validators, IOW, or to inflict local needs on core evergreen |
13:00 |
miker |
(just thought I'd throw that out there) |
13:23 |
|
dcook__ joined #evergreen |
13:28 |
JBoyer |
Speaking of A/T events... I'm trying to add a new helper to Reactor.pm and am running into trouble. It accepts an ou id or potentially an ou object, but it needs to get the id. $org_id = $org_id->{id} if ref $org_id; doesn't work, giving me a "undef error - Not a HASH reference at ..." error for that line. |
13:28 |
JBoyer |
Anyone have any ideas on how to get the id out of an ou object sent to a helper func? |
13:29 |
JBoyer |
(pinging miker, for lack of other names, heh.) |
13:29 |
Dyrcona |
JBoyer: Objects are blessed array refs, just do $org_id->id w/out brackets. |
13:29 |
miker |
yep, what Dyrcona said |
13:29 |
JBoyer |
Aha. I will give that a shot. |
13:30 |
JBoyer |
Thanks |
13:30 |
JBoyer |
Dyrcona++ |
13:30 |
JBoyer |
(I intensely dislike this syntax minutia but I'll spare everyone that schpeal.) |
13:32 |
JBoyer |
miker++ # for verifying. |
13:32 |
Dyrcona |
JBoyer: Well, don't use Perl, use Java.... :) |
13:34 |
miker |
JBoyer: you may want to use a separate variable to avoid changing the environment ... my $oid = ref($org_id) ? $org_id->id : $org_id; |
13:34 |
Dyrcona |
Yeah.. miker++ |
13:34 |
miker |
strictly speaking, unless you have a cleanup module for that A/T, it doesn't matter today. but if stacked reactors become a thing... |
13:36 |
JBoyer |
miker, Dyrcona It's a 3 line sub with a my $org_unit=shift; at line 1. :) I'm adding helpers.get_org_unit_ancestor_at_depth() to Reactor.pm. |
13:36 |
JBoyer |
my $org_id = shift; rather. |
13:37 |
csharp |
hmm - getting a fun error on freshly installed master: http://pastebin.com/3eUZpUcK |
13:37 |
miker |
ah, ok ... NOTHING TO SEE HERE! |
13:37 |
JBoyer |
:) |
13:40 |
miker |
csharp: huh... well, ws should be the id of the workstation, obv, not a string ... recent changes to the staff client? or missing/local changes to the idl? |
13:40 |
JBoyer |
csharp, I suppose it's too much to hope that you're testing some toolbar changes on that install? |
13:41 |
csharp |
I rebuilt the staff client just in case it was my older local one |
13:41 |
csharp |
if someone can easily confirm that it's happening or not, that would help :-) |
13:41 |
csharp |
JBoyer: nope :-/ |
13:42 |
tsbere |
csharp: Close the client, re-run autogen, try again? |
13:42 |
* tsbere |
usually does that on that kind of error, though hasn't seen it with toolbars that he can recall |
13:43 |
csharp |
that didn't do it :-/ |
13:43 |
tsbere |
I'll throw master onto my dev machine and see what happens, then |
13:43 |
tsbere |
Unless someone else beats me to it |
13:45 |
|
krvmga joined #evergreen |
13:45 |
csharp |
I just created a fresh profile in case it was something cached in the profile - still happening |
13:46 |
* tsbere |
is waiting for his dev machine to finish installing master |
13:48 |
csharp |
tsbere: don't bother - it does look like something I've done with the IDL borked it |
13:49 |
csharp |
replacing fm_IDL.xml with the stock master version fixed it |
13:49 |
tsbere |
csharp: Well, good to know. I will let my dev machine finish anyway, in case I want to play with something in EG later so it will have a working version ;) |
13:49 |
csharp |
:-) thanks |
13:52 |
|
krvmga joined #evergreen |
13:57 |
|
remingtron_ joined #evergreen |
13:59 |
|
rgagnon joined #evergreen |
14:00 |
JBoyer |
Dyrcona++ |
14:00 |
JBoyer |
miker++ |
14:01 |
JBoyer |
It's working, huzzah! |
14:01 |
JBoyer |
Notices are going to get a bit of a revamp... uh, eventually. But it will be so nice when someday comes. |
14:21 |
Dyrcona |
So, I've been asked to change the "charge type" of some direct charges on some acq.purchase_order entries. |
14:21 |
Dyrcona |
Where would I find direct charges? |
14:22 |
tsbere |
My first place to look would be reports mentioning the things. I think MVLC has at least one. No clue how it works, I didn't make it. >_> |
14:24 |
jeffdavis |
Dyrcona: you mentioned you guys are using Win10 thin clients, are you running the staff client on those? Does it work ok? |
14:24 |
Dyrcona |
Looks like it is aq.po_item. |
14:24 |
* tsbere |
takes a quick look, assumes some of that is looking at a table/item "non-bibliographic invoice item" |
14:25 |
Dyrcona |
jeffdavis: I believe it does work, but I don't use it. We also don't use it much for circulation. This at the consortium's central site. |
14:26 |
jeffdavis |
ah, ok, thx |
14:26 |
Dyrcona |
tsbere: Yeah, I know what I want to do, now. Thanks for looking with me. :) |
14:26 |
jeffdavis |
csharp: thanks for that note on open-ils-general btw - the thin client thing is definitely something I want to look at with that site, so useful to know it's been a problem in the past |
14:27 |
* Dyrcona |
rarely uses the staff client. |
14:27 |
Dyrcona |
And then, usually just to confirm odd behavior. |
14:31 |
csharp |
jeffdavis: I can point you/the library to one of our libraries that dealt with that - maybe compare notes - if you/they are interested |
14:32 |
csharp |
@seen slink |
14:32 |
pinesol_green |
csharp: I have not seen slink. |
14:34 |
jeffdavis |
csharp: thanks, I may take you up on that |
14:38 |
Dyrcona |
Debian Slink was quite some time ago... ;) |
15:11 |
|
mmorgan joined #evergreen |
15:41 |
pinesol_green |
[evergreen|Mike Rylander] LP#1660059: Protect against null value in group field - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=db7600f> |
16:10 |
csharp |
_bott_: did you make any more progress on tracking down the weird extra parens in the new hold targeter? |
16:11 |
csharp |
I was gonna add a comment to bug 1596595 - but didn't want to duplicate efforts |
16:11 |
pinesol_green |
Launchpad bug 1596595 in Evergreen "Hold targeter features and refactoring" [Wishlist,New] https://launchpad.net/bugs/1596595 |
16:11 |
_bott_ |
csharp: ...perhaps. I changed line 470 in HoldTargeter.pm to simply use $hold->id I haven't seen a recurrence of the error, but it's hardly definitive |
16:14 |
berick |
_bott_: what's the error? |
16:15 |
_bott_ |
berick: query error. Extra set of parens after the ahr.id http://pastebin.com/raw/btwtQfvK |
16:21 |
berick |
_bott_: when it happens do the "targeter: [hold .." log lines looks sane? |
16:22 |
berick |
it should log the value of $self->hold_id with every log entry generated by the targeter |
16:29 |
_bott_ |
berick: I'm not seeing any corresponding errors. ...seems like I might have a race condition with pgpool, as I see a few ACTION_HOLD_REQUEST_NOT_FOUND, but none of those match up to the query errors I've found |
16:32 |
berick |
_bott_: i just mean, from your example error, do you see log lines like: "targeter: [hold 1927426] ..." |
16:33 |
berick |
trying to rule out $self->hold_id being a funky value -- the proces really should die a lot earlier if the hold id in valid, since the first thing it does is fetch the hold by id. |
16:33 |
berick |
s/in valid/is invalid/ |
16:34 |
_bott_ |
berick: I was only logging 'warn', so I don't have anything unless there was an error |
16:34 |
* csharp |
is looking |
16:34 |
berick |
ah |
16:45 |
pastebot |
"csharp" at 64.57.241.14 pasted "full log output with hold targeter v2 error" (170 lines) at http://paste.evergreen-ils.org/44 |
16:45 |
csharp |
berick: ^^ |
16:46 |
berick |
csharp: thanks. |
16:46 |
* berick |
looks |
16:46 |
csharp |
it's not happening when running the hold_targeter_v2.pl script - but at checkin |
16:47 |
_bott_ |
csharp: correct, seems to only occur when it has a single hold id to chew on |
16:47 |
berick |
ok, good to know |
16:47 |
berick |
ah |
16:47 |
berick |
i see it |
16:48 |
berick |
targeter: [hold ARRAY(0x47e23d0)] processing... |
16:48 |
berick |
that array should be an ID |
16:48 |
berick |
so.. |
16:50 |
berick |
in circ, self->retarget is a list |
16:50 |
* berick |
patches |
16:57 |
|
khuckins_ joined #evergreen |
17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:06 |
berick |
csharp: _bott_: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=320cc9fe56d38c79da2da064a68fec746ae3385e |
17:06 |
berick |
pushed to same branch |
17:07 |
|
mmorgan left #evergreen |
17:21 |
|
jvwoolf left #evergreen |
18:14 |
jeff |
oh hey, looks like my session proposal was accepted. |
18:14 |
jeff |
looks like i'm talking about SIP! :-) |
18:19 |
|
bmills1 joined #evergreen |
19:05 |
jeff |
("oh hey", because i noticed on twitter first and was surprised) |
19:37 |
csharp |
berick: thanks - I've put it in place - I'll let you know tomorrow if I see any issues |
19:37 |
csharp |
berick++ |
19:37 |
csharp |
jeff: I never heard back directly either, but s'all good |
19:56 |
|
bmills joined #evergreen |
20:10 |
|
JC-ATS joined #evergreen |
21:07 |
|
ATS-JC joined #evergreen |
21:10 |
ATS-JC |
Hi! I just want to ask if the transcendent bib Sources for electronic resources is available at version 2.3? Because i can only see oclc, system local, and Project Guttenberg. Thanks in advance! |
21:33 |
jeffdavis |
ATS-JC: in theory you can mark any bib source as transcendent, or add your own new bib sources (transcendent or not). I don't know if that can be done by a non-admin user in the staff client, though. |
21:42 |
jeffdavis |
If I were making that change, I would do it by setting the "transcendant" field to true for the appropriate record(s) in the config.bib_source table in the database. Not sure whether there's a way to do it in the client. |