| Time |
Nick |
Message |
| 00:21 |
|
sandbergja joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 07:56 |
|
mantis1 joined #evergreen |
| 07:58 |
|
tlittle joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:40 |
|
rfrasur joined #evergreen |
| 08:53 |
|
alynn26 joined #evergreen |
| 08:58 |
|
collum joined #evergreen |
| 09:06 |
|
Dyrcona joined #evergreen |
| 09:13 |
|
jvwoolf1 joined #evergreen |
| 09:20 |
|
jvwoolf1 left #evergreen |
| 09:21 |
|
jvwoolf joined #evergreen |
| 10:15 |
|
alynn26_away joined #evergreen |
| 10:23 |
|
nfBurton joined #evergreen |
| 10:29 |
mmorgan |
We're beginning the process of anonymizing circs. We think we've covered preserving all the statistics we need, but one thing we can't see a way to preserve is a unique patrons served count. |
| 10:30 |
mmorgan |
For example, how many patrons checked out items in a given month. Is this stat important to other systems. Has anyone found a way to capture that? |
| 10:32 |
jeff |
There are (probably more than) a few ways to accomplish such a thing. |
| 10:33 |
jeff |
One would be to establish the needed measures beforehand and calculate them and preserve them (the totals) before purging/anonymizing. |
| 10:33 |
jeff |
If you want running totals that becomes more difficult. |
| 10:35 |
jeff |
Many of the other approaches involve tradeoffs and risk of reidentification. |
| 10:36 |
jeff |
A simple hash of the user ID is going to be easy to brute force, for example. |
| 10:36 |
csharp |
+1 to jeff for having snapshot counts |
| 10:37 |
jeff |
You can assign random tokens with decay, where patron 123 will always be token XYZ until they have no activity within Y amount of time. |
| 10:37 |
csharp |
you might even consider creating tables in the database to preserve summary totals |
| 10:37 |
jeff |
If patron 123 is active for a year then stops for >Y time, the next time they're active they will get a new token and be seen as a "new" unique user if measuring over the total time. |
| 10:37 |
csharp |
with a cron job that does monthly stats |
| 10:38 |
mmorgan |
We're considering creating tables in the db, but would ideally like the usr_activity table to track checkouts. So we would have patron x checked out y things. No idea what they were, or where, though. |
| 10:38 |
jeff |
And if patron123 is never inactive >Y, then you will always have a non-decayed token mapping, which means your anonymization of that user is near-zero. |
| 10:39 |
jeff |
csharp: related, we've considered an approach for reporting where "all circs are aged circs", to mitigate "we changed this user's profile and now this report for last month gives different values!" |
| 10:45 |
jeff |
mmorgan: that's another promising approach! have you thought about how user purges would affect the counts, or how you'd report on a subset of org units? |
| 10:45 |
jeff |
(or you may not care about those) |
| 10:45 |
jeff |
I feel like I've had this discussion at least once before. We were also talking about relative activity dates/timestamps. |
| 10:46 |
* jeff |
looks |
| 10:47 |
jeff |
Hrm. Google seems to have dropped irc.evergreen-ils.org entirely. |
| 10:47 |
mmorgan |
:-( |
| 10:52 |
mmorgan |
jeff: All good questions! We're just starting to explore the details, so haven't put that all together yet. |
| 10:53 |
nfBurton |
Is there an updated release date for EG 3.6.3? |
| 10:53 |
* mmorgan |
thought there was a bug about adding circ activity to actor.usr_activity, but can't find it. |
| 10:56 |
jeff |
I'm not finding the conversation I was remembering where we discussed relative user activity, or user activity that was day-granular or that didn't repeat until X time since the last event with the same attributes. |
| 11:16 |
Dyrcona |
gmail-- # In the middle of editing a reply email, and Google says, "Please verify it's you." |
| 11:17 |
csharp |
Dyrcona: can you verify you're you here please :-) |
| 11:17 |
csharp |
could be some *other* Dyrcona |
| 11:17 |
* Dyrcona |
isn't here. |
| 11:17 |
Bmagic |
:) |
| 11:18 |
* Dyrcona |
is really Donald Fagen... "Rose darling, my friend...." |
| 11:20 |
* Dyrcona |
don't live in that New York City no more. :) |
| 11:48 |
Dyrcona |
typos-- |
| 11:49 |
Dyrcona |
grep options -L and -l have opposite meanings/effects. Don't use one when you mean the other. :) |
| 11:55 |
|
nfBurton joined #evergreen |
| 11:58 |
|
sandbergja joined #evergreen |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:05 |
|
sandbergja_ joined #evergreen |
| 12:33 |
|
collum joined #evergreen |
| 12:55 |
dbwells |
Well, they say any publicity is good publicity: https://www.bbc.com/news/world-middle-east-56505413 ;) |
| 13:00 |
|
khuckins joined #evergreen |
| 13:04 |
gmcharlt |
dbwells: when hold pull lists go very bad |
| 13:20 |
Dyrcona |
Heh. I saw that story earlier this morning. |
| 13:43 |
jeff |
something something "in transit too long" report. |
| 13:43 |
mmorgan |
Dear Patrons, Delivery of your held items will be delayed... |
| 13:49 |
rfrasur |
lol |
| 13:49 |
rfrasur |
funny story (is it?) - our notices are also delayed. |
| 14:20 |
|
sandbergja joined #evergreen |
| 15:03 |
jeffdavis |
For Postgres to be able to use newly-installed Perl modules, it's necessary to restart Postgres, right? |
| 15:03 |
|
jvwoolf left #evergreen |
| 15:06 |
jeffdavis |
Hm, no, maybe not. |
| 15:09 |
csharp |
jeffdavis: shouldn't require restart |
| 15:10 |
jeffdavis |
Thanks for confirming. I was misreading scrollback in my terminal window. :) |
| 15:12 |
Dyrcona |
Yeah, I was going to say the same, but seems you've figured it out. |
| 15:14 |
Dyrcona |
jeffdavis: Were you going to update the security bug to indicate when a new patch is ready, or did I miss the email? |
| 15:15 |
jeffdavis |
Dyrcona: I will update the bug, I got waylaid yesterday. |
| 15:18 |
|
mmorgan1 joined #evergreen |
| 15:18 |
Dyrcona |
jeffdavis: No problem. I saw the branch got pushed and wondered if you thought it was ready or not. |
| 15:20 |
jeffdavis |
It's probably ready, but I re-checked some display field stuff based on miker's inquiry yesterday and found at least one place where they weren't handled properly (subjects.tt2). That will be true of the pre-3.7 versions as well though. |
| 15:20 |
jeffdavis |
Anyway, hoping to get back to it this aft, otherwise tomorrow. |
| 15:29 |
Dyrcona |
jeffdavis: OK. Good to know. |
| 15:29 |
Dyrcona |
jeffdavis++ |
| 15:40 |
|
rfrasur joined #evergreen |
| 15:49 |
|
mantis1 left #evergreen |
| 16:03 |
miker |
jeffdavis++ |
| 16:32 |
|
sandbergja joined #evergreen |
| 17:14 |
|
mmorgan left #evergreen |
| 17:46 |
|
sandbergja joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:11 |
jeffdavis |
[2021-03-24 15:10:11] /srv/openils/bin/osrf_control [ERR :957485:XMPPReader.pm:131:] XMPP connect failed |
| 18:11 |
jeffdavis |
[2021-03-24 15:10:11] /srv/openils/bin/osrf_control [ERR :957485:EX.pm:66:] Exception: OpenSRF::EX::Jabber 2021-03-24T15:10:11 OpenSRF::Utils::Logger /usr/local/share/perl/5.30.0/OpenSRF/Utils/Logger.pm:243 Jabber Exception: Could not authenticate with Jabber server: |
| 18:13 |
jeffdavis |
^ getting these errors trying to start EG services with master on 20.04, ejabberd is running, users are registered, test message with sendxmpp to router public.localhost seems to work |
| 18:55 |
|
sandbergja joined #evergreen |
| 19:28 |
jeffdavis |
Modifying the standard ejabberd.yml for ejabberd 20.01 per OpenSRF install instructions doesn't do the trick, but just grabbing version of ejabberd.yml from Bill's ansible installer is working. Not immediately sure which options in the default version are problematic. |
| 19:44 |
|
jihpringle joined #evergreen |
| 20:07 |
|
sandbergja joined #evergreen |
