[FEATURE] Implémenter la double écriture des CGU dans l'API acceptLegalDocumenByUserId (PIX-22581).

[Libouk]

🚙 Problème

Dans le cadre de la nouvelle gestion du versioning des CGU pour Pix App, nous avons besoin d’utiliser l'API permettant d’accepter un document légal pour un utilisateur. Cette API, acceptLegalDocumentByUserId, fera une double écriture dans le nouveau et ancien modèle de données.

🍃 Proposition

Ajouter la validation des CGU sur l'utilisateur dans le cas où le document légal à valider sont les CGU et que l'application est Pix App

🔗 Pour tester

Vérifier lors de la validation des CGU à l'inscription que les valeurs liées aux CGU sont bien mises à jour.

Vérifications pour l’ancienne implémentation

• cgu: true
• last-terms-of-service-validated-at: date de validation
• must-validate-terms-of-service: false

Vérifications pour la nouvelle implémentation

• table legal-document-version-user-acceptances correctement remplie

[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.

[EmmanuelleBonnemay]

Proposition globale : actuellement les méthodes de cgu "pix-app" s'appellent par ex acceptPixLastTermsOfService vs acceptPixOrgaLastTermsOfService ; ne faudrait-il pas préciser acceptPixAppLastTermsOfService pour éviter toute hésitation ?

[EmmanuelleBonnemay]

Il me semble qu'il y a un problème fonctionnel dû au usecase acceptLegalDocumentByUser (test fait avec le FT à false)
si nous tombons dans

if (!legalDocument) {
     logger.warn(`No legal document found for service: ${service} and type: ${type}`);
     return;
   }

ou dans 

if (doesUserAcceptanceAlreadyExist) {
      return;
    }

alors il est impossible d'aller au bout de la validation des cgu et d'arriver sur la page authenticated. On reste bloqué sur le clic de la page d'acceptation des cgu qui ne produit aucune action. Vous pouvez reproduire ce scénario facilement s' il n'y a aucun legalDocument pix-app dans la table des legal documents.

C'est lié au fait que le commit ajoute un renvoi de user dans ce usecase (et dans la fonction qui l'appelle : acceptPixLastTermsOfService, (qui se trouve actuellement dans le userRepository)- comme le demande la route api/users/id/pix-terms-of-service-acceptance
Mais ce user n'est pas renvoyé dans les 2 cas cités ci-dessus. (si on maintient l'idée de le renvoyer il faudra donc a minima faire la modif dans ce usecase, pour renvoyer aussi user dans les deux if)
Questions :
- faut-il aller chercher le user ici, ou bien ne rien renvoyer depuis ce usecase, et faire un fetch depuis le domaine IAM ?
- le renvoi d'un user ici crée-t-il des régressions sur Pix Orga ?
- faut-il harmoniser les deux routes/controllers acceptPixLastTermsOfService et acceptPixOrgaTermsOfService pour qu'aucune ne renvoie de user ou qu'elles renvoient toutes les deux des users ?

[lego-technix]

✅ Lu et validé avec succès en équipe

[bpetetot]

✅ Test et Review OK

[pix-service]

🎉 This PR is included in version 5.429.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀