| Time |
Nick |
Message |
| 01:11 |
|
sandbergja joined #evergreen |
| 01:43 |
|
sandbergja joined #evergreen |
| 01:48 |
|
sandbergja joined #evergreen |
| 04:20 |
|
mrisher joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:55 |
|
agoben joined #evergreen |
| 07:44 |
|
Dyrcona joined #evergreen |
| 08:05 |
|
alynn26 joined #evergreen |
| 08:31 |
|
mmorgan joined #evergreen |
| 08:32 |
|
sandbergja joined #evergreen |
| 08:39 |
|
mantis1 joined #evergreen |
| 08:46 |
|
mrisher_ joined #evergreen |
| 08:54 |
|
rfrasur joined #evergreen |
| 09:09 |
|
dbwells joined #evergreen |
| 09:13 |
|
mrisher joined #evergreen |
| 09:14 |
|
jvwoolf joined #evergreen |
| 10:38 |
pinesol |
[evergreen|Jane Sandberg] LP1845241: Use the correct API call to Undelete a bib record - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d7ed1d2> |
| 11:07 |
|
jvwoolf joined #evergreen |
| 11:11 |
|
nfBurton joined #evergreen |
| 11:23 |
gmcharlt |
berick: apropos of bug 1888524, is it intended that the Angular MARC editor not update 005 fields upon record save? |
| 11:23 |
pinesol |
Launchpad bug 1888524 in Evergreen "Angular MARC editor authority undelete does not guarantee reingest" [Medium,New] https://launchpad.net/bugs/1888524 |
| 11:25 |
|
nfBurton95 joined #evergreen |
| 11:25 |
berick |
gmcharlt: it is not intended, an oversight. |
| 11:25 |
|
nfBurton64 joined #evergreen |
| 11:28 |
gmcharlt |
berick: gotcha. |
| 11:28 |
gmcharlt |
berick: before you consider doing anything, I'm starting a thread on the catalogers list asking for general preferences on 005 field updates |
| 11:34 |
* berick |
nods |
| 11:35 |
|
jihpringle joined #evergreen |
| 11:37 |
gmcharlt |
Relevant query sent to the Evergreen Catalogers list: http://list.evergreen-ils.org/pipermail/evergreen-catalogers/2020-July/001610.html |
| 11:46 |
jeff |
So, will that be ten new OU settings, or just one or two with a bitmask? |
| 11:46 |
* jeff |
ducks |
| 11:48 |
Dyrcona |
Ha! |
| 11:54 |
csharp |
I had a thought about dividing settings into different UIs this morning - maybe the same UI but filtered for holds settings, say, if someone enters the "Hold Settings" UI |
| 11:55 |
csharp |
it was more of a brainstorm idea rather than something I've thought out |
| 11:56 |
csharp |
but something like: generic grid that loads the relevant settings based on point of entry |
| 11:57 |
Dyrcona |
We sort of have that already with the filters, but some of the settings are miscategorized or could go in more than one place. |
| 11:57 |
Dyrcona |
I don't personally use the settings interfaces. I make changes in the database via SQL. |
| 11:58 |
* mmorgan |
likes the idea of limiting display of the settings rather than trying to limit the number of settings. |
| 11:58 |
Dyrcona |
There are too many settings. |
| 11:58 |
csharp |
right - it would be similar to the status quo, and maybe still manually filterable, but I think correcting the categories and sorting them into separate UIs would go a long way to addressing the YAOUS problem |
| 11:58 |
mmorgan |
Why too many? |
| 11:58 |
csharp |
probably some are obsolete |
| 11:59 |
Dyrcona |
Because there are too many in my opinion. |
| 11:59 |
Dyrcona |
Operating Evergreen feels like operating a WWI Uboat, with hundreds of valves and who knows what happens when you set them all a certain way. |
| 12:00 |
csharp |
there was a long period in the early teens (weird to say that) where we added feature after feature with accompanying settings and now it's unwieldy and poorly documented |
| 12:00 |
csharp |
right - some settings play unexpectedly/badly with other settings enabled |
| 12:00 |
Dyrcona |
There were too many settings in 2012, and it's worse, now. |
| 12:01 |
Dyrcona |
Just my opinion. I'm sure others disagree. |
| 12:01 |
* mmorgan |
agrees that obsolete ones should be eliminated, and if there are settings that don't really make sense library by library, maybe those should be changed to global flags? Just brainstorming |
| 12:01 |
csharp |
I've stopped training local admins on the Library Settings UI because it's almost all stuff they can't change anyway and getting to the half-dozen that matter to them is pretty difficult |
| 12:02 |
mmorgan |
We don't let folks in the library setting ui. Always wanted to hide things in there so only relevant ones display to authorized staff users. |
| 12:03 |
csharp |
we experimented with the view perms a while back but that resulted in people not being able to use certain vital UIs because they needed view perms to enter them |
| 12:04 |
csharp |
that would need to be separated - perms to use the UIs vs. perms to view the settings |
| 12:04 |
mmorgan |
+1 |
| 12:05 |
|
mrisher_ joined #evergreen |
| 12:05 |
Dyrcona |
I think things should be made more simple, not more complicated, but that requires burning it all down and starting over. |
| 12:06 |
csharp |
probably |
| 12:08 |
mmorgan |
Simple is always good, but would hate to take away library by library options that make things easier for the sake of simplicity. |
| 12:08 |
alynn26 |
I would like to see it in at least two lists, one things systems to change and another things that only Consortium can change. Plus be able to place settings on the System list individually. But a complete rewrite is most likely the best Idea, along with some additional documentation for each individual settings. |
| 12:10 |
Dyrcona |
More and more, I find myself thinking,"It should work like X. If you don't like it, there's the source code." |
| 12:10 |
alynn26 |
I think about it, then something happens |
| 12:10 |
Dyrcona |
:) |
| 12:11 |
Dyrcona |
That something being "coming to one's senses?" :) |
| 12:11 |
alynn26 |
:) |
| 12:28 |
|
alynn26_away joined #evergreen |
| 12:29 |
|
mantis1 left #evergreen |
| 12:35 |
mmorgan |
What are folks doing for sms hold notification? Is anyone using the email gateway, or is everyone using a service provider? Seems like since holds started up again, the email gateway is even more problematic than it used to be. |
| 12:40 |
|
mantis1 joined #evergreen |
| 12:43 |
jeff |
we use Twilio |
| 12:45 |
jeff |
I think Josh Stompro shared code for using flowroute a while back, in bug 1667080 |
| 12:45 |
pinesol |
Launchpad bug 1667080 in Evergreen "Hold SMS - New Reactor - flowroute" [Undecided,New] https://launchpad.net/bugs/1667080 |
| 12:45 |
Dyrcona |
We use the email gateway. |
| 12:46 |
jeff |
we cobbled something together based on our external-to-evergreen notification system and some opt-in user settings. |
| 12:47 |
jeff |
I don't think you're ever going to have a happy experience with email-to-sms gateways. |
| 12:48 |
jeff |
to clarify the above, Twilio and flowroute are both providers of an API for sending SMS messages. |
| 12:52 |
Dyrcona |
It would be nice if the flowroute code were in a form that we could use. And if someone could write a reactor for Twilio, too.... |
| 12:52 |
mmorgan |
Dyrcona: Have you had complaints about patrons not receiving sms messages? |
| 12:52 |
Dyrcona |
Sure, all the time, but we get more complaints about emails. |
| 12:53 |
jeff |
I don't think that an A/T reactor is the proper place for things like flowroute and Twilio, but I might be in the minority there. |
| 12:54 |
Dyrcona |
I don't deal with it directly. I just see the tickets. I think we get way more complaints about email than SMS, but I'm not actually checking. |
| 12:54 |
jeff |
I've interest in making this better, though. |
| 12:55 |
Dyrcona |
jeff: I think we use A/T for a lot of things that it shouldn't be used for, such as marking lost and auto-renewal, but not enough time to implement alternatives. |
| 12:55 |
mmorgan |
I'm getting reports that folks aren't receiving them, I can confirm evergreen is sending, and that email is delivering to the carrier. |
| 12:56 |
Dyrcona |
Then, your responsibility is done. They need to take it up with their carrier, but I suspect stricter anti-spam measures. |
| 12:57 |
alynn26_away |
We get a lot of bounce backs, Usually is because the carrier has tightened down the anti-spam measures. |
| 12:57 |
jeff |
mmorgan: what you report experiencing is unsurprising, and one of the main reasons why we don't use email to sms here. |
| 12:58 |
* mmorgan |
nods |
| 13:11 |
jeff |
We've not encountered issues with SMS deliverability so far (knock on wood). |
| 13:13 |
mmorgan |
Thanks for the input, helps as we look for a solution. |
| 13:13 |
mmorgan |
Dyrcona++ jeff++ alynn26_away++ |
| 13:28 |
jeff |
We've sent about 5,500 messages in the last 30 days. Our last "normal" month was probably February. |
| 13:29 |
|
jihpringle joined #evergreen |
| 13:29 |
jeff |
So looking at Feb, we had about 7300 messages and paid about $63. |
| 13:30 |
jeff |
The pricing went up a little bit with Verizon's introduction of additional fees. Carrier fees were about $9 of that $63. |
| 13:30 |
agoben |
jeff, what all notices do you send that way? And what's your total service population? |
| 13:31 |
jeff |
service area population is around 90,000 |
| 13:31 |
jeff |
and we're sending opt-in SMS for hold available and for items due (courtesy and overdue) |
| 13:32 |
agoben |
jeff++ Thanks! |
| 13:33 |
jeff |
Our volume is such that the limit of 1 message per second for a ten digit number isn't something that impacts us. |
| 13:33 |
jeff |
And the messages are transactional, not bulk. |
| 13:33 |
jeff |
So we don't need to pay for a shortcode. |
| 13:34 |
agoben |
Yeah, assuming a similar scale, we'd be looking at well over 100K a month, so guessing we wouldn't be so lucky |
| 13:34 |
agoben |
(Messages, that is) |
| 13:35 |
jeff |
yeah, you'd be starting at $750/mo before carrier charges (Verizon and US Cellular at the moment) |
| 13:36 |
agoben |
mmhmm |
| 13:41 |
Dyrcona |
We're at 151K per month. |
| 13:41 |
Dyrcona |
Assuming February is "normal" 'cause we're way down since. |
| 13:45 |
Dyrcona |
Hm... I should limit that to complete events. I'll bet close to half of those were invalid. |
| 13:46 |
alynn26_away |
where close to that with completed events. |
| 13:47 |
Dyrcona |
Oh! It's a lot lower if I limit to state = 'complete': 23,624 for Feb. |
| 13:48 |
jeff |
under $300 even for the worst-case scenario of them all being US Cellular customers. :-) |
| 13:50 |
|
rfrasur joined #evergreen |
| 13:50 |
Dyrcona |
Not my decision. I don't get to spend money, except on Evergreen hardware. |
| 13:50 |
* Dyrcona |
waves to rfrasur |
| 13:51 |
pinesol |
[evergreen|Josh Stompro] LP#1754387 - User Buckets - Pending Users Enhancement - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=61f19f6> |
| 13:52 |
* jeff |
sells Dyrcona a very expensive Raspberry Pi bundled with SMS service |
| 13:52 |
Dyrcona |
heh! |
| 13:52 |
|
agoben joined #evergreen |
| 13:53 |
Dyrcona |
@dessert |
| 13:53 |
* pinesol |
grabs some Mint Chocolate Chip Ice Cream for Dyrcona |
| 13:58 |
* JBoyer |
considered for a hot second buying an industrial GSM modem to try to go straight from server to cell network, but nothing ever came of it. |
| 13:59 |
JBoyer |
Would certainly have fixed the "email gateways can be unreliable" issue though. |
| 14:03 |
Dyrcona |
Yeahp. |
| 14:04 |
* Dyrcona |
is fighting with the Pinebook Pro a bit. Thunderbird doesn't seem to respect the font settings. It seems to work after I change them, until I read a new message in a different folder. |
| 14:04 |
Dyrcona |
Anyway, that's off-topic. |
| 14:05 |
|
rfrasur joined #evergreen |
| 14:08 |
Dyrcona |
Ooh. I think I found the magic sauce for the fonts. Just uncheck "Use fixed font for plain text messages." |
| 14:11 |
pinesol |
[evergreen|Jason Stephenson] LP#1775940: Archived Penalties/Messages does not Respect Date Range - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=63c4ac1> |
| 14:32 |
jeff |
JBoyer: I would not recommend that approach. :-) |
| 14:32 |
jeff |
(not sure how serious you were) |
| 14:33 |
JBoyer |
I was at the "ooh, that looks neat" stage of window-shopping. Not actually spend-some-money serious. :) |
| 14:33 |
JBoyer |
(Also, I'm sure the carriers would have been disinclined to acquiesce to my request.) |
| 14:33 |
* Dyrcona |
prefer carrier pigeon. |
| 14:34 |
Dyrcona |
What about an SMS app on a cell phone? :) |
| 14:35 |
jeff |
the phantom voice of Geoffrey Rush just said "Means 'No.'" somewhere in my head. |
| 14:38 |
Dyrcona |
:) |
| 14:49 |
csharp |
mmorgan: make sure SPF and (possibly) DMARC is properly configured for both the sending domain and any other domains that use their own sending addresses as the "from" within Evergreen |
| 14:50 |
csharp |
https://mxtoolbox.com/ is your friend :-) |
| 14:50 |
csharp |
https://pines.georgialibraries.org/dokuwiki/doku.php?id=admin:settings:spf PINES docs on SPF/Evergreen |
| 14:52 |
Dyrcona |
csharp: Does SPF make a big difference with SMS gateways? |
| 14:57 |
csharp |
from what I can tell, it does (or did last time I looked) |
| 14:58 |
Dyrcona |
All right. I've never tried to figure it out. I know it can be important for sending regular email, so worth doing anyway. |
| 14:59 |
jeff |
csharp: is there a reason you don't recommend includes in your SPF documentation? do your IP addresses just rarely change, so it hasn't been a hassle up to this point to get hundreds of libraries to update their SPF records? |
| 15:00 |
Dyrcona |
jeff: We ran into some limit at MVLC when we tried to include multiple domains' SPF records into ours. Some of the members were asking that we add their vendors for instance. |
| 15:02 |
Dyrcona |
The number 1024 pops into my head, but I'm not sure if that was bytes or entries, once everything was expanded. |
| 15:04 |
Dyrcona |
Oh, yeah: Don't exceed 10 lookups: https://sendgrid.com/docs/ui/account-and-settings/spf-limitations/#:~:text=SPF%3A%20Don't%20Exceed%20Ten,use%20of%20the%20include%20modifier. |
| 15:05 |
Dyrcona |
If you include records that include others, you can very easily hit that limit. |
| 15:06 |
mmorgan |
csharp++ |
| 15:08 |
mmorgan |
Just discovered that some of the triggers were ending up in error state because the enviroment was missing :-/ Not sure how that happened. |
| 15:09 |
csharp |
jeff: we rarely change IPs, and yeah it was super disruptive when we last changed in April 2019 |
| 15:09 |
csharp |
it's a huge mess - though easier now that we manage most of the libraries' email in GSuite |
| 15:09 |
jeff |
do you manage their DNS also? |
| 15:16 |
csharp |
in most cases, yes |
| 15:16 |
csharp |
it's a patchwork, but most of the 159 counties/64 systems let us manage as much as we can |
| 15:17 |
* jeff |
nods |
| 15:25 |
|
sandbergja joined #evergreen |
| 15:33 |
|
mantis1 left #evergreen |
| 15:37 |
|
AFloyd__ joined #evergreen |
| 15:39 |
JBoyer |
mmorgan, one issue with email gateway SMS delivery that I've seen before is the user brings in a phone from MVNO carrier X, that leases spectrum from multiple nationwide carriers and doesn't offer their own email gateway. Since you usually can't tell by looking at the phone which of the big 4 carriers actaully communicates with it you have to guess. :-/ |
| 15:39 |
JBoyer |
lp 1777677 would help with that. |
| 15:39 |
pinesol |
Launchpad bug 1777677 in Evergreen "Test notification method" [Wishlist,Confirmed] https://launchpad.net/bugs/1777677 |
| 15:45 |
|
sandbergja joined #evergreen |
| 15:45 |
mmorgan |
JBoyer: Good to know, and Yes, that enhancement sounds great. Much more elegant than suggesting that they text themselves call numbers from the opac to test ;-) |
| 15:58 |
jeff |
That being perhaps the second largest reason why we don't use email to SMS gateways. :-) |
| 15:59 |
|
rfrasur joined #evergreen |
| 15:59 |
* jeff |
bumps reshelving interval to 96 hours |
| 16:00 |
Bmagic |
I can't find the bug about editing the UNCATALOGED call number row (-1) anyone have a bearing on that bug somewhere? |
| 16:06 |
Bmagic |
bug 1839859 |
| 16:06 |
pinesol |
Launchpad bug 1839859 in Evergreen "Block editing the dummy bib and call number used by pre-cat items" [Undecided,Confirmed] https://launchpad.net/bugs/1839859 |
| 16:09 |
mmorgan |
Maybe bug 1849334 is a duplicate? That one has a fix :) |
| 16:09 |
pinesol |
Launchpad bug 1849334 in Evergreen "Precat owning library should not be editable" [Undecided,Confirmed] https://launchpad.net/bugs/1849334 |
| 16:14 |
|
jihpringle joined #evergreen |
| 16:15 |
mmorgan |
Bmagic^^ |
| 16:15 |
Bmagic |
oh! nice |
| 16:16 |
Bmagic |
mmorgan++ |
| 16:16 |
Bmagic |
simple fix! csharp++ |
| 16:16 |
mmorgan |
csharp++ |
| 16:17 |
Bmagic |
Didn't make the cut for the releases between Feb and now? What does it need? |
| 16:18 |
Bmagic |
the two bugs (def dups) were created within two months of eachother :) |
| 16:20 |
* mmorgan |
will mark 1839859 as the dup since the other has the fix |
| 16:38 |
csharp |
just needs a commit to master - since I'm the author, I'll defer to someone else to commit the fix |
| 17:15 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:39 |
|
abowling1 joined #evergreen |
| 18:52 |
|
jihpringle joined #evergreen |
| 18:55 |
|
abowling joined #evergreen |
| 19:11 |
gmcharlt |
sandbergja: do you have privs to open milestones in LP? if so, milestones can be reopened and closed if you need to correct a targeting |
| 19:12 |
sandbergja |
oh, I think I do! |
| 19:12 |
sandbergja |
let me try |
| 19:13 |
sandbergja |
That worked! Thanks, gmcharlt! |
| 19:13 |
gmcharlt |
cool! |
| 21:35 |
|
sandbergja joined #evergreen |
| 23:34 |
|
abowling left #evergreen |
| 23:34 |
|
abowling joined #evergreen |
