[TECH] Mise en place de l'EDA sur l'anonymisation

[P-Jeremy]

☀️ Problème

L'anonymisation d'un utilisateur (admin via POST /api/admin/users/{id}/anonymize, ou l'utilisateur lui-même via DELETE /api/users/me) est aujourd'hui portée par un unique service, anonymize-user.service.js (contexte privacy), qui appelle directement les repositories/API de 4 autres contextes (identity-access-management, team, legal-documents, prescription/learner-management).

Ce couplage rend le service difficile à faire évoluer et empêche d'isoler l'échec d'un traitement sans bloquer toute la chaîne.

⛱️ Proposition

Bascule de l'anonymisation vers l'architecture événementielle mise en place dans #17159 : publication d'un AnonymizeUserEvent, auquel chaque bounded context réagit via son propre EventHandler, de façon autonome et découplée :

• identity-access-management : moyens de connexion, dernières connexions, login, révocation des tokens, demande de réinitialisation de mot de passe
• legal-documents : documents légaux acceptés
• prescription/learner-management : apprenants et participations aux campagnes
• team : memberships et certification-center-memberships

AnonymizeUserEvent est un integration event consommé par plusieurs bounded contexts : il est donc déclaré dans shared/domain/events/ (et non dans privacy), pour que privacy reste le seul producteur sans devenir une dépendance des contextes consommateurs. La règle dependency-cruiser qui exemptait spécifiquement les évènements de domaine des vérifications de dépendances inter-contextes n'est donc plus nécessaire et a été retirée : shared étant déjà une dépendance autorisée pour tous les contextes, aucune exception particulière n'est requise.

L'ancien anonymize-user.service.js est supprimé.

🧴 Remarques

• Chaque handler est couvert par un test d'intégration dédié.
• Le test acceptance sur la route anonymize-user vérifie que chaque EventHandler reçoit le payload attendu.

🏊 Pour tester

• En local (Pix Admin, superadmin@example.net / pix123) : sur la fiche d'un utilisateur, déclencher l'anonymisation, puis vérifier en base que l'utilisateur, ses memberships, ses moyens de connexion, ses participations et ses documents légaux sont bien anonymisés/désactivés.
• Ou en tant qu'utilisateur connecté sur mon-pix (certif-success@example.net / pix123) : DELETE /api/users/me, même vérification.

Penser à démarrer le traitement des jobs en local ! cd api && npm run start:job

[pix-bot-github]

Choisir les applications à déployer :

• API | 👩‍💻 Dashboard Scalingo
• App (.fr) – App (.org) | 👩‍💻 Dashboard Scalingo
• Orga (.fr) – Orga (.org) | 👩‍💻 Dashboard Scalingo
• Certif (.fr) – Certif (.org) | 👩‍💻 Dashboard Scalingo
• Junior | 👩‍💻 Dashboard Scalingo
• Admin | 👩‍💻 Dashboard Scalingo
• API MaDDo | 👩‍💻 Dashboard Scalingo
• Audit Logger | 👩‍💻 Dashboard Scalingo

Important

N'oubliez pas de déployer l'API pour pouvoir accéder aux fronts et/ou à l’API MaDDo.

[bpetetot]

Test OK

[EmmanuelleBonnemay]

Lu et testé avec succès

[lego-technix]

La description de la PR n’indique pas dans la proposition le comportement souhaité en cas d’erreur de l’anonymisation dans un des contextes.

De même dans la description des tests fonctionnels il n’y a la description d’un cas d’erreur.

Serait-il possible d’ajouter ces 2 points dans la description de la PR SVP ? 🙏

[lego-technix]

Actuellement sur le déploiement d’une RA pour Pix App n’est pas coché, est-ce volontaire ? Pourtant l’auto-anonymisation depuis le compte d’utilisateur sur Pix App avec envoi d’email est un cas pertinent à tester.

[lego-technix]

🧪 J’ai effectué les tests fonctionnels indiqués dans la PR et des tests fonctionnels en cherchant à générer des erreurs. Tout me semble très bon, avec une toute petite remarque sur le cas suivant :

1. Dans Pix Admin, un admin a un onglet ouvert pour anonymiser un utilisateur et lance
2. Dans Pix App, cet utilisateur s’auto-anonymise
3. Dans Pix Admin, l’admin lance l’anonymisation → la ConflictError 400 n’est pas gérée côté Pix Admin et l’UI est cassée et ne répond plus.

Néanmoins c’est mieux que ce qui se passe sur dev actuellement où, pour ce cas-ci, l’utilisateur se retrouve anonymisé 2 fois 🤯 et où 2 audit logs sont enregistrés dans l’Audit Logger. Donc 👏👏👏 cela démontre que l’EDA est bien adaptée pour gérer ce cas d’anonymisation et se comporte mieux que l’architecture précédente 👏👏👏