| Time |
Nick |
Message |
| 02:45 |
|
geoffsams joined #evergreen |
| 05:33 |
|
edoceo joined #evergreen |
| 05:42 |
|
hopkinsju_ joined #evergreen |
| 05:43 |
|
gsams joined #evergreen |
| 06:29 |
|
StomproJ joined #evergreen |
| 07:05 |
|
TARA joined #evergreen |
| 07:05 |
|
genpaku joined #evergreen |
| 07:35 |
|
bwicksall_ joined #evergreen |
| 07:36 |
|
gmcharlt_ joined #evergreen |
| 07:37 |
|
jeff joined #evergreen |
| 07:37 |
|
jeff joined #evergreen |
| 07:37 |
|
pastebot joined #evergreen |
| 07:37 |
|
edoceo joined #evergreen |
| 07:38 |
|
Bmagic joined #evergreen |
| 07:40 |
|
Callender joined #evergreen |
| 07:42 |
|
book` joined #evergreen |
| 07:56 |
|
rlefaive joined #evergreen |
| 08:08 |
|
collum joined #evergreen |
| 08:14 |
|
Dyrcona joined #evergreen |
| 08:16 |
|
ericar joined #evergreen |
| 08:20 |
|
rlefaive_ joined #evergreen |
| 08:40 |
|
rjackson_isl joined #evergreen |
| 08:47 |
|
mmorgan joined #evergreen |
| 09:15 |
|
mrpeters joined #evergreen |
| 09:31 |
|
kmlussier joined #evergreen |
| 09:45 |
|
serflog joined #evergreen |
| 09:45 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 09:47 |
csharp |
@coffee [someone] and [someone] and [someone] and [someone] and [someone] and [someone] and [someone] and [someone] |
| 09:47 |
* pinesol_green |
brews and pours a cup of Sumatra Danau Toba, and sends it sliding down the bar to RBecker and ericar and RBecker and bshum and mmorgan and StomproJ and book` and rlefaive |
| 09:49 |
Dyrcona |
@tea |
| 09:49 |
* pinesol_green |
brews and pours a pot of Dragon Pearl Jasmine, and sends it sliding down the bar to Dyrcona (http://ratetea.com/tea/harney/dragon-pearl-jasmine/1320/) |
| 09:49 |
Dyrcona |
@coffee csharp |
| 09:49 |
* pinesol_green |
brews and pours a cup of Costa Rica Micro Lot "Pepe" Honey Processed, and sends it sliding down the bar to csharp |
| 09:49 |
csharp |
aw yeah |
| 09:50 |
|
yboston joined #evergreen |
| 09:56 |
mmorgan |
@coffee kmlussier |
| 09:56 |
* pinesol_green |
brews and pours a cup of El Salvador Los Planes Pacamara, and sends it sliding down the bar to kmlussier |
| 10:03 |
jeff |
"press one to replay, or two to acknowledge receiving this message" <-- something which we realized was a bad idea a long time ago |
| 10:03 |
jeff |
amusingly, i still see people press 2 when getting a holdshelf call. |
| 10:04 |
jeff |
(and it still does what it always did -- we just removed the prompt suggesting it) |
| 10:04 |
jeff |
anyone want to guess what our primary reason for removing it was? :-) |
| 10:05 |
|
mmorgan1 joined #evergreen |
| 10:09 |
|
mtj_ joined #evergreen |
| 10:25 |
|
jwoodard joined #evergreen |
| 10:29 |
|
sarabee joined #evergreen |
| 10:30 |
|
rlefaive joined #evergreen |
| 10:36 |
|
Callender joined #evergreen |
| 10:37 |
|
collum joined #evergreen |
| 10:42 |
|
Dyrcona joined #evergreen |
| 10:42 |
|
mmorgan joined #evergreen |
| 10:58 |
|
rlefaive joined #evergreen |
| 11:00 |
csharp |
jeff: sorry if this is obvious, but why did it end up being a bad idea? |
| 11:02 |
* kmlussier |
was stumped. |
| 11:03 |
berick |
maybe if they don't press 2, they can say they didn't get the call |
| 11:04 |
berick |
say, for overdue items |
| 11:04 |
kmlussier |
But it's a holdshelf call. |
| 11:05 |
berick |
oh, i was thinking patron calls in general |
| 11:09 |
Bmagic |
What circumstances cause the holds shelf list show a hold with a "status" of canceled? Looking at the DB, the hold does not have a cancel_time but the screen shows that it's canceled. Is that based on expire_time? |
| 11:13 |
berick |
hmm, it should only show canceled if the cancel_time is set |
| 11:13 |
Bmagic |
very odd |
| 11:14 |
berick |
at least according to the code that determines the hold status (Holds.pm:_hold_status()) |
| 11:17 |
jeff |
csharp, kmlussier, berick: people would get confused when listening to their voicemail -- pressing 1 and/or 2 did things other than the prompt said, because it was no longer a live call, etc. |
| 11:18 |
jeff |
since we weren't actually doing much differently at that point with "answered/completed" vs "acknowledged", we opted to remove the prompt rather than try to revise it. |
| 11:18 |
jeff |
"if you are listening to this call live and not as a voicemail, you may press 1 to replay or 2 to acknowledge..." nope. |
| 11:19 |
berick |
jeff: "press <command to delete all voicemails> to acknowledge!" |
| 11:19 |
jeff |
if it had been important to us, we might have re-worded or used AMD or similar to only say that when we detected it as a "live" call, but as it was simplification was the best route. |
| 11:20 |
jeff |
berick: some voicemail systems used 2 to repeat and 1 to go to previous message, so if it was your only message both options repeated the message |
| 11:21 |
berick |
yeah, that would be annoying |
| 11:21 |
jeff |
to make matters worse, the message was short so it repeated 2-3 times -- meaning the user was more likely to think "well, I have to pick one of these options -- but neither one is working!" |
| 11:22 |
jeff |
anyway, the things you don't think about until things have had some real world use. |
| 11:23 |
csharp |
exactly! |
| 11:25 |
jeff |
upgraded our asterisk instance this week, after our previous hardware from 2007 became unreliable. a decent amount of config syntax had changed, but overall it was a pretty smooth transition. |
| 11:25 |
jeff |
"refactoring by attrition", or something like that. |
| 11:25 |
csharp |
heh |
| 11:25 |
jeff |
surest way to ensure hardware failure: create a vm to replace the hardware in question. |
| 11:26 |
miker |
jeff: it just got sad and refused to train its replacement, eh? |
| 11:27 |
csharp |
"I guess SOME people just don't think what I do is important anymore" |
| 11:29 |
jeff |
it was actually an impressive failure mode. |
| 11:29 |
jeff |
desktop pc from 2007 put into service as an asterisk server in 2008. reliable until just this week. |
| 11:30 |
jeff |
system hung when i was connected to it remotely. power cycled, hung again as i put it under moderate disk+network+cpu load. |
| 11:31 |
dbwells |
miker++ # positive EG press in Library Journal |
| 11:31 |
jeff |
when it failed, it went *thunk*, then after about 3 seconds the VGA signal went out. |
| 11:31 |
jeff |
the *thunk* was presumably the drives parking. |
| 11:32 |
miker |
wow... |
| 11:32 |
jeff |
anyway, backups plus git repos plus both drives (software RAID) were 100% readable. i threw it in a spare machine on the bench and copied everything off one last time. |
| 11:32 |
jeff |
new VM to replace it was ready and has been making calls since yesterday. |
| 11:33 |
jeff |
er, making calls since monday, making "real" calls since tuesday. :-) |
| 11:34 |
|
brahmina joined #evergreen |
| 11:34 |
miker |
jeff: asterisk vm, is that safer now? IIRC, it used to be very taboo |
| 11:34 |
|
rjackson_isl_ joined #evergreen |
| 11:35 |
jeff |
safer now, in the right environment. |
| 11:35 |
miker |
google seems to concur :) |
| 11:36 |
* Dyrcona |
looks 'round Obélix. |
| 11:37 |
|
gmcharlt joined #evergreen |
| 11:38 |
Dyrcona |
Oddly enough that still makes sense with the omission. |
| 11:42 |
|
sandbergja joined #evergreen |
| 11:42 |
* Dyrcona |
is pondering a setup to test edi pusher and edi fetcher. |
| 11:43 |
miker |
dbwells: thanks :) |
| 11:44 |
Dyrcona |
A script to set up the account, etc. in the database, along with a canned order message and a canned response message. |
| 11:44 |
Dyrcona |
Configure ftp either locally or elsewhere. Put the messages in place and test. |
| 11:45 |
* Dyrcona |
likely needs help with the EDI messages. |
| 11:46 |
|
edoceo joined #evergreen |
| 11:59 |
|
bmills joined #evergreen |
| 12:03 |
|
Christineb joined #evergreen |
| 12:25 |
jeff |
automatic library quiz game based on MARC records |
| 12:26 |
|
mmorgan1 joined #evergreen |
| 12:26 |
jeff |
Originally broadcast on television in 2008 and Narrated by Harrison Ford, this NOVA Documentary on Sociobiology focused on what animal? |
| 12:27 |
dbs |
The echidna! |
| 12:27 |
jeff |
Ants! |
| 12:31 |
|
yboston_ joined #evergreen |
| 12:43 |
|
gsams joined #evergreen |
| 12:50 |
|
dkyle1 joined #evergreen |
| 12:58 |
jeff |
miker: regarding earlier conversation about Asterisk -- virtualization is also much easier when you don't have hardware to worry about like digium cards/etc. |
| 13:08 |
|
jihpringle joined #evergreen |
| 13:34 |
|
tarac_ joined #evergreen |
| 14:03 |
|
bmills joined #evergreen |
| 14:24 |
StomproJ |
jeff; Do you check for the Default Phone notification setting when sending out phone calls? Can I see your A/T for your AstCalls? I thought that it was set to pick the default number if that was entered, but just looked at it again and the exmaples just show grabbing the day_phone number. |
| 14:26 |
StomproJ |
jeff; miker; We also use asterisk running on a VM without telephony hardware (Using flowroute SIP provider) and we haven't had any problems. Being able to place 20 calls at once is nice. |
| 14:28 |
Dyrcona |
There's that overloaded acronym again.... |
| 14:36 |
jeff |
StomproJ: we do it outside of A/T, but I can tell you that the logic we use is roughly: at time of hold becoming available for pickup, determine voice and text prefs from user settings (or default if no user settings), then we base voice number on the user setting opac.default_phone or the value of actor.usr.day_phone (ignoring any invalid-looking values in both) |
| 14:37 |
|
tarac__ joined #evergreen |
| 14:37 |
jeff |
StomproJ: for text_number we use the first valid-looking value in either the user setting opac.default_sms_notify or actor.usr.day_phone |
| 14:37 |
jeff |
StomproJ: we ignore other actor.usr phone fields at present |
| 14:37 |
|
mrpeters1 joined #evergreen |
| 14:38 |
jeff |
this has a side effect of the staff-client-side hold per-hold notification settings being something we just ignore. we don't use per-hold, just per-user-at-time-of-hold-being-ready. |
| 14:39 |
|
rashma_away joined #evergreen |
| 14:39 |
jeff |
we place max one voice call per day per phone number per pickup library, but for texts we'll do up to two messages. |
| 14:39 |
|
rhamby_ joined #evergreen |
| 14:39 |
|
mnsri joined #evergreen |
| 14:39 |
jeff |
after that we back off for the rest of the day, and if they still have not-previously-notified-for holds they'll get new notifications the next day. |
| 14:41 |
jeff |
we also do a bit where you might get a text saying "EXAMPLE TITLE ONE is now ready for pickup at LIBRARY" followed by "Multiple items including EXAMPLE DVD SIX are ready for pickup at LIBRARYNAME" |
| 14:41 |
StomproJ |
jeff, thanks. Ahhhhh, that is the bit that I was missing. The example hold pickup astCall event def should probably get the phone from target.0.phone_notify instead of the target.0.usr.day_phone... |
| 14:42 |
jeff |
so in theory you might have seventeen items ready for pickup now -- you need to check your account or come get them if you want to know what's ready. |
| 14:43 |
jeff |
One thing I'm trying to figure out lately is the best way to tell a patron "no, we can't send you any more texts until you reverse the STOP message that you issued on DATE" |
| 14:43 |
jeff |
I think it'll just be "email + handout at desk" |
| 14:43 |
jeff |
It's rare, but happens. |
| 14:44 |
jeff |
(all they need to do is send a message to our number) |
| 14:45 |
StomproJ |
jeff, I started a bug report on trying to do something similar with the official telephony stuff - lp#1516143, someday I hope to work on that. |
| 14:45 |
jeff |
But in at least one case we've disabled text notification for a patron in response to a STOP message and placed a note on their account, but then the patron has re-enabled text notifications without realizing that that won't work now. |
| 14:45 |
jeff |
In theory something like message center might help there also -- the note we placed was only visible to staff. |
| 14:45 |
* jeff |
looks at bug 1516143 |
| 14:45 |
pinesol_green |
Launchpad bug 1516143 in Evergreen "Wishlist: Telephony - eg-pbx-allocator.pl limit calls to a phone number per day" [Undecided,New] https://launchpad.net/bugs/1516143 |
| 14:45 |
jeff |
ah |
| 14:47 |
jeff |
yup, I've read that bug before. :-) |
| 14:47 |
StomproJ |
Jeff, after a branch proceded to check in one item every half an hour for a customer one day and they received 6 phone calls that afternoon. :-) |
| 14:48 |
jeff |
Yeah. |
| 14:49 |
StomproJ |
Jeff++ thanks for all the details. |
| 14:49 |
jeff |
Nobody here has ever caused 20+ text messages to be delivered to a patron, or had phone calls go out at 1 AM. |
| 14:57 |
Dyrcona |
Phone calls at 1 AM? What is this, Fidonet? :) |
| 15:12 |
|
wsmoak joined #evergreen |
| 15:14 |
|
ericar_ joined #evergreen |
| 15:15 |
|
ericar joined #evergreen |
| 15:43 |
dbs |
Dyrcona++ |
| 15:43 |
dbs |
@quote add Phone calls at 1 AM? What is this, Fidonet? |
| 15:44 |
dbs |
err, whatevs |
| 15:45 |
|
jeffdavi1 joined #evergreen |
| 15:46 |
|
mmorgan joined #evergreen |
| 15:47 |
|
Callender_ joined #evergreen |
| 15:49 |
|
bwicksall joined #evergreen |
| 15:58 |
|
tarac joined #evergreen |
| 16:03 |
|
ericar joined #evergreen |
| 16:03 |
|
dkyle1 joined #evergreen |
| 16:03 |
|
gmcharlt joined #evergreen |
| 16:03 |
|
collum joined #evergreen |
| 16:03 |
|
Callender joined #evergreen |
| 16:03 |
|
sarabee joined #evergreen |
| 16:03 |
|
graced joined #evergreen |
| 16:03 |
|
bwicksall_ joined #evergreen |
| 16:03 |
|
pinesol_green joined #evergreen |
| 16:03 |
|
phasefx joined #evergreen |
| 16:05 |
|
mmorgan1 joined #evergreen |
| 16:11 |
|
dkyle1 joined #evergreen |
| 16:11 |
|
gmcharlt joined #evergreen |
| 16:11 |
|
collum joined #evergreen |
| 16:11 |
|
sarabee joined #evergreen |
| 16:11 |
|
graced joined #evergreen |
| 16:11 |
|
pinesol_green joined #evergreen |
| 16:11 |
|
phasefx joined #evergreen |
| 16:13 |
jeffdavis |
Is there an easy way to reindex a bib record for just a single config.metabib_field index? |
| 16:13 |
|
pinesol_green` joined #evergreen |
| 16:14 |
|
collum_ joined #evergreen |
| 16:14 |
jeffdavis |
I want to update a bunch of TCNs and I'd prefer to just update the TCN index. |
| 16:15 |
|
gmcharlt_ joined #evergreen |
| 16:16 |
|
sarabee joined #evergreen |
| 16:17 |
|
phasefx joined #evergreen |
| 16:18 |
jeff |
I regret not keeping closer track of user settings over time with regard to hold notifications: we did see many people turn on text notifications, some in addition to but some in place of email notifications. I'm curious how many turn off voice notification after enabling text notification, etc. |
| 16:19 |
jeff |
Then there are those like me who just have all the notification options turned on. |
| 16:19 |
jeff |
I get an text, then an email, then a voice call... and then I pass a co-worker in the building and they say "we have a book for you! did you see?" :-) |
| 16:20 |
jeff |
a text, even. |
| 16:20 |
jeff |
(almost listed the email first, but generally the text goes out (and gets my attention) first) |
| 16:21 |
jeff |
StomproJ: since you've opened bug 1570072, I'll ask the question I've asked others before: do you see patrons intentionally using one-off hold-specific notification settings, and do you have insight into why they do? |
| 16:21 |
pinesol_green` |
Launchpad bug 1570072 in Evergreen "Hold request update notification preferences on change" [Undecided,New] https://launchpad.net/bugs/1570072 |
| 16:22 |
StomproJ |
jeff, no, I just assumed that others have since it is designed as it is. I would be fine with doing away with the per hold notification. I just assume that there are sites that need that functionality. 1570072 would get rid of one of the gotchas for us. |
| 16:26 |
jeff |
Just did a quick check -- we've had no patrons voice concern / objection / negative feedback regarding us removing the option for per-hold notification options. |
| 16:26 |
StomproJ |
Maybe it just sticks around because everyone assumes someone is making use of that. I just see constant errors being made at the point of placing holds. |
| 16:27 |
* jeff |
nods |
| 16:27 |
brahmina |
jihpringle: this is the page where google describes what to do if you have the "this site might be hacked" message... https://support.google.com/websearch/answer/190597?hl=en |
| 16:27 |
brahmina |
opp... wrong channel |
| 16:27 |
StomproJ |
Lets add a 12 digit phone number today, lets choose SMS but not select a carrier, etc. |
| 16:29 |
|
graced joined #evergreen |
| 16:30 |
|
dkyle joined #evergreen |
| 16:37 |
miker |
StomproJ: the hold-specific email and sms values are intended to allow people to, say, request a hold for pickup at a library where they're going to be on vacation, and have the call go to the location they're staying. Or to say "alert my SO when this hold appears -- I won't be looking at my SMS for whatever reason" ... in a statewide consortium it's more important than for single (general) locality |
| 16:38 |
miker |
the behavior has intent behind it, IOW |
| 16:39 |
|
jihpringle_ joined #evergreen |
| 16:39 |
|
mnsri_ joined #evergreen |
| 16:39 |
|
mtcarlsoz joined #evergreen |
| 16:40 |
miker |
(and, not "developer intent", but library requested behavior) |
| 16:40 |
|
jeffdavi1 joined #evergreen |
| 16:42 |
jeff |
Capturing the user intent would probably address most issues while still supporting the desired use case. |
| 16:42 |
jeff |
"I am intentionally overriding the notification settings for this hold", essentially. |
| 16:43 |
|
jeffdavis joined #evergreen |
| 16:45 |
miker |
jeff: maybe ... that's more checkboxes and thinking at hold placement time (and attendant screen "clutter"), but a discussion worth having |
| 16:46 |
miker |
well, not "maybe", it would, but there are tradeoffs |
| 16:50 |
kmlussier |
Rather than an additional checkbox at hold placement time, I think it would be better to have a prompt at the time a phone number is changed that says something like "This number is used on x # of unfufilled holds. Do you want to update the phone number on those holds?" |
| 16:59 |
|
tarac joined #evergreen |
| 17:03 |
gmcharlt_ |
kmlussier: bug 1570091 |
| 17:03 |
pinesol_green` |
Launchpad bug 1570091 in Evergreen "webstaff: final sprint2 merge" [Wishlist,New] https://launchpad.net/bugs/1570091 |
| 17:04 |
gmcharlt_ |
@later tell Dyrcona lp 1570091 has the final special merge for webstaff sprint2 (cataloging) |
| 17:04 |
pinesol_green` |
gmcharlt_: The operation succeeded. |
| 17:04 |
|
gmcharlt joined #evergreen |
| 17:08 |
kmlussier |
gmcharlt++ |
| 17:11 |
jeff |
i think this is fewer checkboxes, if you don't count the disabled ones: https://jsfiddle.net/fjsega2s/3/ |
| 17:11 |
jeff |
drat. missed kmlussier. |
| 17:15 |
jeff |
and of course that's a very very quick-and-dirty mockup |
| 17:15 |
jeff |
(not to scale, and i didn't have time to paint it) |
| 17:40 |
|
pinesol_green joined #evergreen |
| 18:23 |
|
bmills joined #evergreen |
| 19:50 |
|
mcarlson joined #evergreen |
| 22:03 |
|
dcook joined #evergreen |
| 22:36 |
|
dcook__ joined #evergreen |
| 22:39 |
|
jeff_ joined #evergreen |
| 22:52 |
|
jeff_ joined #evergreen |
| 23:06 |
|
mcarlson joined #evergreen |
| 23:07 |
|
jeff_ joined #evergreen |
| 23:18 |
|
wjr joined #evergreen |
