Option to send warning email before deleting user

[dylex]

Proposed change

We've gotten some requests to send a warning email a day before deleting users, so I'm thinking of implementing a warning mode to do so. Opening this in case anyone else has either worked on or is interested in such a thing.

My current idea is to have a mode that says "warn (by sending a somehow configurable email) instead of delete" and run multiple copies in parallel, one in warning mode with a shorter timeout. (We already run multiple to kill servers sooner than deleting users, though I realize this may no longer be necessary.)

In our case emails are usernames, though I realize in other cases they may not be, so there's also that aspect to consider.

If this seems outside the scope of this project, feel free to close this and we'll work on it separately.

[manics]

I think some sort of notification framework is useful, but email is just one form of possible notification, I can see others wanting notifications through a chatroom, or some other method. Instead of hardcoding multiple methods which are difficult to maintain and test what do you think of adding a hook into the culler which could run an external script (anything executable, doesn't have to be python)? The parameters could be passed on the command line or as environment variables, maybe you could serialise the user and server model objects as JSON?

[1kastner]

I agree with @manics that hardcoding something might have many inevitable and negative consequences. There are already several notification solutions out there, e.g. https://github.com/notifme/notifme-sdk or https://github.com/HealthByRo/universal_notifications could do the job. It looks like massive overhead? But somewhere the email of the user to notify needs to be stored. Maybe we should also keep track of whether there were error messages (such as 'email does not exist') etc. and think about reacting to it.

The question remains how the notification should be sent. @manics advocates for an executable. Somehow that also needs to digest some input because at least the (unique) user name needs to be handed over. I have had quite bad experiences with such things in one project. When an executable is not invoked by the logged in user in the bash, depending on the circumstances sometimes the used codecs of the terminal change since not all environment variables are always loaded. This is important if some user names contain unicode characters (as it might be the case for some (!) French or German names). I don't wish anybody needs to track down such an error again so I would rather prefer a webhook solution. This would require running another server - something else that needs frequent maintenance and potentially crashes. Nothing is for free.