Gestion des transitions d'état de profil
Lorsqu'on supprime un profil, un utilisateur, ou si l'on voulait bannir véritablement un profil, ou plus encore supprimer ses messages, ou même encore si l'on veut temporairement rejeter une demande de profil, on doit pouvoir gérer la notion de transition d'état.
Pour faire ça on pourrait implémenter une machine à états avec des transitions longues, etc. mais ça me paraît bien trop complexe pour notre besoin. Il me semble qu'on a seulement besoin de stocker, en plus de l'état courant (status
, un état cible target_status
), et de supporter un système événementiel pour traiter le passage d'un état à l'état cible.
Pour cela il faut probablement rajouter une commande en CLI et lancer un second conteneur pour traiter les tâches (je ne veux pas partir en usine à gaz avec du Celery). Ce second conteneur scanner régulièrement les transitions demandées, et applique les éventuelles fonctions de transition.
Une fonction de transition peut être enregistrée avec 3 paramètres :
- l'état actuel, potentiellement omis
- l'état cible
- un délai depuis la dernière modification du profil, potentiellement omis
Si les trois matchent (sauf si omis évidemment), alors la fonction est appelée sur le profil. Si elle retourne vrai, alors l'état est remplacé par l'état cible et l'état cible placé à null.
A suivre quelques exemples d'utilisation.
Pour gérer la suppression de compte ou de profil. Aujourd'hui on peut supprimer un compte ou profil, mais les données ne seront pas supprimées de l'application, ni même le profil.
Il nous faudrait donc deux états : DELETED
et PURGED
. Le premier supprime le compte, le second nettoie les données associées.
Lorsque l'utilisateur ou l'administrateur supprime ou purge le compte, celui-ci reste en état ACTIVE
, mais on ajoute un état cible DELETED
ou PURGED
.
La routine d'effacement est enregistrée pour tout état source, vers l'un des deux états de destination, avec un éventuel délai (qui est le délai de suppression effective). Cette routine utilise les fonctions spécifiques, définies éventuellement dans le template d'application (Mastodon, etc.) pour effectuer l'effacement du compte sur l'application.
Une fois la suppression réussie, la routine supprime le lien utilisateur-profil et retourne vrai.
Pour gérer le bannissement de compte. Aujourd'hui on peut bloquer un compte, mais le compte n'est pas forcément bloqué sur l'application même.
Il nous faut conserver l'état BLOCKED
.
Lorsque l'administrateur bloque le compte, celui-ci reste en état ACTIVE
, mais a une cible en BLOCKED
.
La routine de blocage est enregistrée pour tout état source, vers l'état BLOCKED
, sans délai. Elle utilise les fonctions spécifiques, définies éventuellement dans le template d'application pour bloquer le compte sur l'application, forcer la déconnexion de l'utilisateur, etc.
Une fois le blocage réussi, la routine retourne vrai.
Pour gérer la demande de compte avec rejet.
Il nous faut ajouter un état REJECTED
.
Lorsque l'administrateur refuse la demande, celle-ci resete en état REQUESTED
, mais a une cible en REJECTED
.
La routine de rejet est enregistrée sur REQUESTED
=> REJECTED
, avec un délai configurable, délai autorisé pour réagir. Lorsqu'elle est exécutée, elle supprime le profil demandé pour libérer le nom d'utilisateur.
Cela laisse à l'utilisateur le temps de répondre éventuellement au motif de rejet. Eventuellement à chaque réponse on met à jour la dernière modification du profil, pour repousser d'autant le délai de suppression.