nettoyage printemps : deployer le module de manière ciblée

[odelcroi]

### Tasks
- [ ] https://github.com/tchapgouv/tchap-infra/issues/2695
- [ ] https://github.com/tchapgouv/tchap-infra/pull/2678
- [ ] https://github.com/tchapgouv/tchap-infra/pull/2719
- [ ] https://github.com/tchapgouv/tchap-infra/pull/2674
- [ ] https://github.com/tchapgouv/tchap-infra/pull/2729
- [ ] https://github.com/tchapgouv/tchap-product/issues/320
- [ ] https://github.com/tchapgouv/tchap-product/issues/321

Besoins

Le nettoyage est différencié par instance (fin des négociations : 26 avril) :

Cas spécifiques

• interieur : Gendarmerie a transmis une liste, on attend un retour pour le reste du ministère de l'Intérieur.
• education : envoyer le mail d'expiration, en isolant 4 domaines pour lesquels on a reçu les exports et déjà supprimé les comptes : ac-versailles.fr, ac-creteil.fr, ac-paris.fr, ac-aix-marseille.fr
• justice : Liste réceptionnée et comptes supprimés : aucun mail à envoyer aux agents

Pas d'activation du module pour ces instances car une autre solution est en cours de définition :

• finances : les exclure du nettoyage de printemps car ils pourront nous communiquer les comptes à supprimer de tous les domaines MEFSIN début juin grâce à une étude interne
• intradef : attendre le retour du correspondant

Activation du module de nettoyage de printemps :

• diplomatie : envoyer le mail à tous les utilisateurs
• agent : envoyer le mail à tous les utilisateurs
• agriculture : envoyer le mail à tous les utilisateurs
• collectivites : envoyer le mail à tous les utilisateurs
• culture : envoyer le mail à tous les utilisateurs
• devdurable : envoyer le mail à tous les utilisateurs
• dinum : envoyer le mail à tous les utilisateurs
• elysee : envoyer le mail à tous les utilisateurs
• externe : envoyer le mail à tous les utilisateurs
• pm : envoyer le mail à tous les utilisateurs
• social : envoyer le mail à tous les utilisateurs
• ssi : envoyer le mail à tous les utilisateurs

Procédure de désactivation de compte

procédure de désactivation de comptes en partenariat avec les correspondants ministeriels : 
- créer une tache "ops" d'export de tous les emails des users sur l'instance
- envoyer cet export au correspondant
- le correspondant renvoie le meme fichier, avec le meme format, en laissant uniquement les comptes qu'il faut désactiver
- créer une tache "ops" de désactivation de comptes avec cette liste

Strategie de deploiement

Pre-requis : Deploiement des clients web et mobile

1er deploiement en production

Activation du module avec configuration suivante - sur dinum :

• Délai d'expiration : 40 jours (pour tomber au 15 juin)
• Délai d'envoie de renouvellement avant date d'expiration: 30 jours, 7 jours, 3 jours
• redemarrage synapse
• Délai d'expiration : 180d
• redemarrage synapse

2e deploiement en production

Pas d'activation du module pour ces instances :

• [x] justice
• [x] finances
• [x] intradef

Activation du module avec configuration suivante :

• [x] dinum
• [x] elysee
• [x] externe
• [x] pm
• [x] diplomatie
• [x] agent
• [x] dev-durable
• [x] ssi
• [x] social
• [x] agriculture
• [x] culture
• [x] collectivites
• [x] interieur :
  • exclure gendarmerie.interieur.gouv.fr
• [x] education :
  • exclure ac-versailles.fr, ac-creteil.fr, ac-paris.fr, ac-aix-marseille.fr

Procedure commune :

• Changement de configuration:
  • Délai d'expiration : 43 jours (pour tomber au 1er juillet)
  • Délai d'envoie de renouvellement avant date d'expiration: 30 jours, 7 jours, 3 jours (1er juin, 24 juin, 28 juin)
• redemarrage synapse - background worker
• Changement de configuration:
  • Délai d'expiration : 180d
• redemarrage synapse - all

Note de dev

Comment différencier l'expiration de compte sur une instances

exemple use case : différencier sur une instance par domaine experimentation : https://github.com/tchapgouv/tchap-product/issues/294 exemple fictif

• gendarmerie : pas d'expiration
• les autres : 1er juillet 2024 (et pas de nouvelle expiration avant 6 mois)

comment ?

option 1: activer le module en modifiant le code du module pour prendre en compte les domaines

option 2: activer pour le module pour tout le monde, jouer sur la date d'expiration

• définir la date d'expiration "a la mano"
• period : 6 mois

commentaires :

• définir la date d'expiration "a la mano" : ca peut couter cher en ops
• à l'initialisation du module et au redémarrage de synapse (qqs minutes d'interruption de service) : il met à jour les périodes d'expiration si elle n'existe pas

Pour définir à la mano :

• SQL : à étudier
• API : (userIds) on peut réutiliser, faire une op-tasks, écrit dans la base directement

ATTENTION : on a besoin d'activer le module pour avoir l'API, donc procédure envisagée :

• il faut activer le module (restart synapse)
• override les dates d'expiration par API