| Time |
Nick |
Message |
| 00:47 |
|
adam_reid joined #evergreen |
| 01:08 |
|
adam_reid joined #evergreen |
| 01:17 |
|
adam_reid joined #evergreen |
| 02:56 |
|
adam_reid joined #evergreen |
| 04:16 |
|
adam_reid joined #evergreen |
| 05:36 |
|
adam_reid joined #evergreen |
| 07:07 |
|
adam_reid joined #evergreen |
| 08:26 |
|
adam_reid joined #evergreen |
| 08:46 |
|
mmorgan joined #evergreen |
| 08:49 |
|
mmorgan1 joined #evergreen |
| 09:20 |
|
Dyrcona joined #evergreen |
| 10:23 |
|
collum joined #evergreen |
| 10:50 |
jeff |
Bmagic: regarding SMS, we've always avoided the SMTP gateway methods and send SMS messages directly via an API provider, since probably 2013 or so? I think we took steps to ensure that SMS was included as a visible option for patrons in their account, without ever enabling the overall SMS org unit setting, and thus the sms provider dropdown isn't shown/required. I'd have to look. For that option, |
| 10:51 |
jeff |
Stompro's branch is possibly a better start than trying to make sense of how we threw it together here. |
| 10:51 |
jeff |
oh, and I've exceeded IRC message length. oops. |
| 10:53 |
Dyrcona |
Bmagic: KCLS and CWMARS use messagebee. |
| 10:55 |
jeff |
we do not use messagebee. |
| 10:58 |
gmcharlt |
I've added a new official tags, angular21 |
| 10:58 |
gmcharlt |
with any luck, it won't be relevant for long, but in the short term I think it will be useful for collocating bugs related to the recent Angular bump |
| 11:00 |
Dyrcona |
gmcharlt++ |
| 11:09 |
|
adam_reid joined #evergreen |
| 11:17 |
|
adam_reid joined #evergreen |
| 11:19 |
collum |
Bmagie: KCPL also uses MessageBee. MessageBee has its own email-sms-gateway which we have named Kenton County Public Library - SMS Provider, and we disabled all the other carriers. So staff only have one choice. The gateway is only used for the Opac Call Number feature, and for Send Test Text in the patron record. |
| 11:20 |
Dyrcona |
Our provider is "I agree to receive SMS messages." or something like that. :) |
| 11:20 |
collum |
I like that better than ours. |
| 11:28 |
mmorgan1 |
Our carrier is "No carrier required" Not ideal, it would be nice to have a more graceful solution. |
| 11:47 |
eby |
like jeff we use an api service so not attached to the gateway infrastructure being there but there are plenty of third party like unique it sounds that offer to replace that type of service. i think we originally looked at some hardware options like smseagle that provide it with a SIM. So cleaning up the list so it doesn't have any real carriers would probably be at least useful. |
| 11:48 |
eby |
but for the action.hold_request there seemed like there was wide interest in the notifrication conf session to remove the per hold notify fields |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:09 |
Bmagic |
Thanks everyone eby++ Dyrcona++ collum++ jeff++ |
| 12:10 |
Bmagic |
I think Evergreen needs an overhaul in this department, and I think the vision should be native support for as many API providers as possible. Perhaps starting with Flowroute since we have production code in a branch that we can play with |
| 12:10 |
Bmagic |
like we do with stripe, paypal, ect |
| 12:12 |
Bmagic |
I'm not sure about other countries in the world, and their cell provider sms gateway support, so, it's probably a good idea to leave that functionality available behind some kind of a setting switch |
| 12:13 |
Dyrcona |
Bmagic: Plug and play modules, similar to added content. |
| 12:13 |
Bmagic |
It seems possible to flip a switch on a per org unit basis to line up the OPAC and the triggers and the staff client patron registration page to be orientied towards the API approach vs. the gateway approach |
| 12:16 |
Dyrcona |
With MessageBee we're using action triggers. These can be configured on a per org unit basis. |
| 12:17 |
Bmagic |
exporting xml files feels a bit hacky |
| 12:18 |
Dyrcona |
Maybe it is, but it works. Not every provider would have to work that way. |
| 12:18 |
Dyrcona |
Action triggers execute code; the code can be anything... |
| 12:19 |
* Dyrcona |
has to be afk for a bit. |
| 12:19 |
Dyrcona |
lunch time. |
| 12:48 |
|
adam_reid joined #evergreen |
| 12:52 |
* goood |
mumbles in REST ... https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Trigger/Reactor/CallHTTP.pm |
| 12:54 |
goood |
there's GOT to be a "pay per sms" service that takes an api key, recipient, and message via url... right? (anyway, yes, let's work toward not using email-to-sms) |
| 13:05 |
|
adam_reid joined #evergreen |
| 13:15 |
jeff |
yes, but that doesn't get you all the way there. i'll try to find more time. |
| 14:06 |
|
adam_reid joined #evergreen |
| 14:08 |
* Dyrcona |
adjusts to new glasses. |
| 14:33 |
|
adam_reid joined #evergreen |
| 14:53 |
|
adam_reid joined #evergreen |
| 14:55 |
eby |
berick: am i correct that you have things like email.notices.all, email.notices.overdue and the interface handles checking the all if staff check all the options in notify.email group, etc. still digging through the angular stuff |
| 15:06 |
berick |
eby: sort of. we don't have an 'email.notices.all' setting, though. we just have per-notice opt in settings (notification.courtesy.today.email, notification.hold.pickup.email, ...). Opting into to a group (notify.email) is the same as opting in to each individual notice type. But yes, the UI just papers over that where needed. |
| 15:07 |
berick |
some UIs let you pick individual notice types, others just let patrons pick by grouping (i want all email notices) |
| 15:09 |
berick |
in EG main, the new open-ils.actor.settings.notify.opt_ins.crud API does most of that for you |
| 15:12 |
eby |
yeah trying to match up with that. saw in your example the all so was curious. From the angular it seems like selecting/unselecting the group toggles the individual user settings so wanted to make sure |
| 15:14 |
eby |
thanks. will be a bit before can test the angular side but can at least backport/test the opt_ins |
| 15:25 |
* jeff |
also needs to catch up with the new opt-in settings, and see where it may or may not work for us |
| 16:33 |
Dyrcona |
Ok... Didn't think that query would need a distinct. |
| 16:42 |
|
jihpringle joined #evergreen |
| 16:47 |
eby |
not sure who else was in the opt-in talk/discussion at the conference but I can probably send something to the list about the hold level notify fields |
| 17:00 |
Dyrcona |
Maybe I should ask this over in #postgresql, but I'm trying to get a list of duplicate bibs by oclc number, but I only wan the lowest matching bib number "on the right." That is if a matches b and c, i only want tuples with a,b and a,c and not b,c... |
| 17:01 |
Dyrcona |
I already have to do a distinct apparently because I'm matching on a field that is apparently repeated in some records. |
| 17:02 |
Dyrcona |
I'm trying to clean up the output manually by sorting and removing "duplicates" with a regex, and I'm not convinced that is the best way to do it. |
| 17:03 |
Dyrcona |
Though after several passes the regex approach may have worked. |
| 17:13 |
|
mmorgan left #evergreen |
| 17:15 |
jeff |
eby: i was not in that talk, but i was interested. do you know if there is a summary or slides available? |
| 17:15 |
eby |
slides are up https://drive.google.com/file/d/1_MCBASMm1BPU-vU7JufGuW6Ztz2mMEYT/view |
| 17:15 |
eby |
they are moving in same direction as b erick but hasn't seen the new code yet |
| 17:16 |
eby |
but using user settings to specify global boolean sms / email / phone / etc |
| 17:16 |
eby |
stop using opac.hold_notify |
| 17:16 |
eby |
and was general consensus in the room that per hold notify makes no sense and causes more issues |
| 17:17 |
eby |
with updating the hold settings on patron change, etc |
| 17:17 |
jeff |
also, I've had conversations here and elsewhere regarding removing some/all per-hold notification options. found some with this search: http://irc.evergreen-ils.org/evergreen/search/?nick=jeff&q=carrier |
| 17:17 |
Dyrcona |
Well. per hold notify makes a certain sense, but I'll agree it causes enough confusion to outweigh its usefulness. |
| 17:17 |
jeff |
stop using opac.hold_notify? hrm. |
| 17:19 |
eby |
well i think they were going for more clear not just hold related but when there was discussion there were multiple that wanted hold / overdue / courtesy broken out |
| 17:20 |
eby |
so the slides are more let's just make hold_notify broken out into global sms / email / etc for all notices but the discussion went the other way |
| 17:21 |
Dyrcona |
Do I understand correctly: 1 place (each) for email or sms values, then a setting for each notification to say which one to use? |
| 17:21 |
jeff |
i support keeping per-hold exceptions in some ways/cases, mostly as exceptions and with some UI guardrails. |
| 17:22 |
jeff |
thanks for the slides link. good place for me to start! |
| 17:23 |
Dyrcona |
jeff: I think we'd have to keep that as an exception. It's hard to take a "feature" away that people might actually use (even if rarely). |
| 17:24 |
|
Dyrcona left #evergreen |
| 17:24 |
|
Dyrcona joined #evergreen |
| 17:25 |
jeff |
yeah, I got a phone call in between the first and second part of that message and ended up repeating myself with "exception". |
| 17:25 |
Dyrcona |
Multiple monitors can lead to hitting a key combo in the wrong window.... :) |
| 17:26 |
Dyrcona |
There is a use case for "I want to get notified differently for this hold or these holds." It should be an exception rather than the rule. |
| 17:29 |
eby |
Dyrcona: yeah i think you have it right. The initial proposal from the work biblio is doing with sms was move to a global Notifications: [] email [] sms [] etc. vs the 'hold' label. They ran out of time but I also think simplifying what all needs updating when a patron replies STOP / automating may have been a concern to be compliant |
| 17:29 |
eby |
but quite a few in the room were wanting holds: x y z, overdue: x y z, courtesy: x y z |
| 17:30 |
* jeff |
makes note to also review matches for this search: http://irc.evergreen-ils.org/evergreen/search/?nick=jeff&q=per-hold |
| 17:31 |
Dyrcona |
eby: I can see someone wanting to get sms for holds and email for overdue and/or courtesy notices. |
| 17:31 |
eby |
that's our number one request |
| 17:31 |
Dyrcona |
Our SMS vendor handles the STOP messages, so we don't worry about it in Evergreen, but I can see that becoming a concern for the ILS. |
| 17:35 |
* Dyrcona |
wonders how long before we get a ticket about a patron not getting hold notifications, and the reason is that they replied STOP without thinking about the consequences.... It's probably already happened. |
| 17:36 |
eby |
And yeah the hold level fields remaining and becoming an override, not something that has to be updated on contact changes makes sense |
| 18:45 |
|
jihpringle joined #evergreen |
| 20:04 |
|
adam_reid joined #evergreen |
