[FEATURE] Modifier l'appel api/users/me pour qu'il fonctionne avec le nouveau modèle (PIX-22584)

[EmmanuelleBonnemay]

🚙 Problème

Afin de mettre en place le versionnement des CGU de Pix App, il est nécessaire de modifier l’API permettant de récupérer leur valeur afin de se baser sur le nouveau modèle (hors feature toggle, les nouveaux attributs sont ajoutés aux anciens et ils sont tous disponibles).

🍃 Proposition

• Sur l’appel GET /api/users/me, récupérer les informations de CGU en appelant la nouvelle API getLegalDocumentStatusByUserId du contexte legal-document

• Modifier la récupération des attributs en utilisant le résultat de l’API:
  cgu = true si status = accepted ou update-requested
mustValidateTermsOfService: true ou false en fonction du status (conservé temporairement pour compatibilité)
  true si status égal à requested ou update-requested
lastTermsOfServiceValidatedAt : date d’acceptation retournée par l’API (conservé temporairement pour compatibilité)

• Ajouter un nouvel attribut en utilisant le résultat de l’API:
  termsOfServiceStatus : status d’acceptation (accepted, requested, update-requested, not-applicable)

• Ajouter un nouvel attribut en utilisant le résultat de l’API:
  pixAppTermsOfServiceDocumentPath : documentPath sur le status d’acceptation

• Sérialiser le nouvel attribut pix-app-terms-of-service-status sur l’appel GET /api/users/me

🦵 Remarques

Point d'attention sur la date d'acceptation dont je ne suis pas sure.

🔗 Pour tester

• Quand le FT est activé et désactivé, (donc dans tous les cas ci-dessous) les attributs suivants doivent apparaître sur la route /api/users/me :

-- cgu
-- last-terms-of-service-validated-at
-- must-validate-terms-of-service
-- pix-app-terms-of-service-status
-- pix-app-terms-of-service-document-path

• Quand le FT est activé :

-- Faire une connexion sans ajouter de legal document ni d'acceptance pour Pix App et constater que l'utilisateur est renvoyé vers la page de validation des cgu.
Constater aussi dans les logs de l'api que le usecase getLegalDocumentStatusByUserId revient avec un
WARN logger.warn(Unknown legal document version found for ${service} and ${type});
Vérifier aussi que que deux attributs du user ont été forcés dans la réponse au /api/users/me : cgu = false, mustValidateTermsOfService = true, et pix-app-terms-of-service-status = "requested"
Explication : Il n'y a pas de legalDocumentStatus. Donc la méthode notFound du legalDocumentStatus renvoie un REQUESTED, et toute réponse REQUESTED - qui peut se produire comme ici quand on ne trouve pas de legalDocumentStatus, ou bien quand on ne trouve pas du tout d'acceptance pour cette utilisateur - force user.cgu à false et user.mustValidateTermsOfService à true (cela se passe à la ligne 442 du userRepository.getWithPixAppTosStatus

-- Rajouter une version de legal-document mais pas de legal-document-version-user-acceptances :
node src/legal-documents/scripts/add-new-legal-document-version.js --type 'TOS' --service 'pix-app' --versionAt '2020-01-01'
et noter l'id de cette version.
-- Constater que la connexion avec un élève (hermione@example.net) ne dirige pas l'utilisateur vers la page des cgu mais vers sa homepage, et que pix-app-terms-of-service-status = "not-applicable"
-- Constater que la connexion avec un "non élève" (harry-cover@example.net) redirige l'utilisateur vers la page des cgu avec un status pix-app-terms-of-service-status = "requested" sur la route /api/users/me

-- Rajouter une deuxième version des cgu dans la table legal-document-versions, postérieure à la première :
node src/legal-documents/scripts/add-new-legal-document-version.js --type="TOS" --service="pix-orga" --versionAt="2028-11-30"
Rajouter une acceptance d'un utilisateur de votre choix, mais pour la première version uniquement :
pix=# insert into "legal-document-version-user-acceptances" ("legalDocumentVersionId", "userId", "acceptedAt") values (1002, {id de l'utilisateur}, now());
Connectez-vous, constatez que l'utilisateur est redirigé vers la page d'acceptation des cgu, avec un cgu=true et pix-app-terms-of-service-status = "update-requested" sur la route /api/users/me

- Quand le FT est désactivé :

-- utilisateur ayant déjà validé les cgu et à jour :
données de départ en base : cgu=true, mustValidateTermsOfService=false
résultat de la tentative de connexion : pas de redirection vers la page des cgu

-- utilisateur ayant déjà validé les cgu et pas à jour :
données de départ en base : cgu=true, mustValidateTermsOfService=true
résultat de la tentative de connexion : redirection vers la page des cgu
//ici le last-terms-of-service-validated-at devient null dans la réponse de /api/users/me > c'est tout à fait attendu à cause du buildForLegacyPixAppCgu et du userRepository.getWithPixAppTosStatus

-- utilisateur n'ayant jamais validé les cgu et devant les valider (cette situation est a priori théorique, car toute création de compte se fait avec cgu=true) :
données de départ en base : cgu=false, mustValidateTermsOfService=true
résultat de la tentative de correction : redirection vers la page des cgu
//attention ici cgu devient true dans la réponse de /api/users/me > c'est tout à fait attendu à cause du buildForLegacyPixAppCgu et du userRepository.getWithPixAppTosStatus

-- utilisateur n'ayant jamais validé les cgu et n'ayant pas à les valider (un élève)
données de départ en base : cgu=false, mustValidateTermsOfService=false, lastTermsOfServiceValidatedAt = null
résultat de la tentative de connexion : pas de redirection vers la page des cgu
//attention ici cgu devient true dans la réponse de /api/users/me > c'est tout à fait attendu à cause du buildForLegacyPixAppCgu

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

[lego-technix]

✅ FAIT : Relecture du code

[Libouk]

Func OK

[lego-technix]

✅ Lu et testé fonctionnellement avec succès avec Firefox 🦊

[bpetetot]

Je suggère de faire un découpage des appels différents pour séparer les responsabilités.

1. on récupère le user (Comme avant)
2. on récupère les tos pix app via legalDocumentApiRepository et on passe tosStatus directement à UserWithActivity qui contient la logique

Suggested change

	const user = await userRepository.get(authenticatedUserId);
	const tosStatus = await legalDocumentApiRepository.getPixAppTosStatus(authenticatedUserId);
	const shouldSeeDataProtectionPolicyInformationBanner = user.shouldSeeDataProtectionPolicyInformationBanner;
	return new UserWithActivity({
	user,
	tosStatus,
	hasAssessmentParticipations,
	codeForLastProfileToShare,
	hasRecommendedTrainings,
	shouldSeeDataProtectionPolicyInformationBanner,
	});

3. UserWithActivity contient la logique du modèle

class UserWithActivity {
  constructor({
    user,
    tosStatus,
    hasAssessmentParticipations,
    codeForLastProfileToShare,
    hasRecommendedTrainings,
    shouldSeeDataProtectionPolicyInformationBanner,
  }) {
    Object.assign(this, user);

    this.hasAssessmentParticipations = hasAssessmentParticipations;
    this.codeForLastProfileToShare = codeForLastProfileToShare;
    this.hasRecommendedTrainings = hasRecommendedTrainings;
    this.shouldSeeDataProtectionPolicyInformationBanner = shouldSeeDataProtectionPolicyInformationBanner;

    // new tos
    this.pixAppTermsOfServiceStatus = tosStatus.status;
    this.pixAppTermsOfServiceDocumentPath = tosStatus.documentPath;

    // legacy tos
    this.cgu = tosStatus.status === STATUS.ACCEPTED || tosStatus.status === STATUS.UPDATE_REQUESTED;
    this.mustValidateTermsOfService =
    tosStatus.status === STATUS.REQUESTED || tosStatus.status === STATUS.UPDATE_REQUESTED;
    this.lastTermsOfServiceValidatedAt = tosStatus.acceptedAt;
  }
}