Warn expiring users #56

missytake · 2022-10-01T15:06:37Z

closes #21

the idea is to warn users a certain timespan before their accounts run out:

if their token is 1year or longer, a month, a week, and a day before expiration date
if their token is 1month or longer, a week and a day before expiration date
if their token is 1week or longer, a day before expiration date
if it's shorter than that, after 3/4 of the expiration notice, they get told how much they have left either in minutes or hours.

right now, the expiration warnings are triggered by the prune loop; this is a bit unfortunate as it means that we have to initialize another deltachat.account object for the mailadm bot, and can't reuse the bot object. Maybe that's fine, it just complicates the handling a bit.

I tried it out manually, works so far. There are 2 tests, one of them could be more minimal I guess.

Does the database migration need a test?

src/mailadm/conn.py

src/mailadm/db.py

missytake · 2022-10-01T19:12:21Z

That's how it looks so far - it would be reeeeally nice to have this in a legit "provider chat" in the future <3

There is #57 to make this a bit nicer already :)

missytake · 2022-10-04T09:40:45Z

We called and decided that we will not support the use case of running mailadm without a bot; the prune thread will only be started as soon as we have a working bot account object.

src/mailadm/app.py

src/mailadm/conn.py

src/mailadm/app.py

src/mailadm/conn.py

tests/test_conn.py

hpk42

thanks for the nice work and tests. It's a bit intricate if the policy (when to warn) changes to change all the tests but that's ok for now i guess.
Having the prune_loop re-use the bot account would be good and removing the redundancy as commented. thanks!

src/mailadm/conn.py

src/mailadm/util.py

hpk42 · 2022-10-06T11:48:47Z

src/mailadm/conn.py

+            if user.ttl >= year:
+                if user.warned == 0 and user.date + user.ttl < sysdate + month:
+                    timeleft = "30 days"
+                elif user.warned == 1 and user.date + user.ttl < sysdate + week:
+                    timeleft = "7 days"
+                elif user.warned == 2 and user.date + user.ttl < sysdate + day:
+                    timeleft = "1 day"


only occurs to me now (sorry) but what if for some reason the bot doesn't run for a few days, and then performs this expiry check? Will we not send a message "expired in 7 days" but it might only be "4 days" actually?
We are only ever warning about "X days" so maybe there can be helper function that computers the number of remaining days irrespective how often expiry-checking is performed?

Maybe the message should be "You account will expire at UTC-DATE, about N days from now."

good point. Problem: imo we can't expect users to know in which timezone they are. Maybe we can avoid timezone specifics? for most users a date would be enough, and if the time is shorter, just saying how many hours it will take should be enough.

sure, we are anyway missing localization as well.

hpk42 · 2022-10-06T11:50:19Z

src/mailadm/conn.py


-    def __init__(self, addr, date, ttl, token_name):
+    def __init__(self, addr, date, ttl, token_name, warned=0):


why does it need a default of 0 here?

src/mailadm/conn.py

tests/test_conn.py

hpk42 · 2022-10-06T12:18:42Z

tests/test_conn.py

+def test_users_to_warn(conn, monkeypatch):
+    yeartoken = conn.add_token("1y", token="asd1", expiry="1y", prefix="tmp.")
+    monthtoken = conn.add_token("1m", token="asd2", expiry="1m", prefix="tmp.")
+    weektoken = conn.add_token("1w", token="asd3", expiry="1w", prefix="tmp.")
+    daytoken = conn.add_token("1d", token="asd4", expiry="1d", prefix="tmp.")
+
+    yearuser = conn.add_email_account(yeartoken)
+    monthuser = conn.add_email_account(monthtoken)
+    weekuser = conn.add_email_account(weektoken)
+    dayuser = conn.add_email_account(daytoken)


a bit skeptical of this test_users_to_warn functions -- a bit intricate to follow and a lot of boilerplate. When we change the logic/ warning rhythm it might also break easily. but not sure it's worth to refactor now. The other point (of having a get_users_to_warn that produces messages fitting tot he current time) is probably more important.

hpk42

better improve the warnings to be less timing (downtime) sensitive

…piration

Co-authored-by: holger krekel <[email protected]>

missytake · 2023-01-07T17:58:59Z

This needs to be done again, but it only makes sense after we decided on #78.

missytake commented Oct 1, 2022

View reviewed changes

src/mailadm/conn.py Outdated Show resolved Hide resolved

missytake commented Oct 1, 2022

View reviewed changes

src/mailadm/db.py Outdated Show resolved Hide resolved

missytake changed the title ~~WIP: Warn expiring users~~ Warn expiring users Oct 1, 2022