pix
pix copied to clipboard
[TECH] Ne pas charger les acquis en même temps que le profil cible (PIX-5643)
:unicorn: Problème
Actuellement les acquis sont lus depuis le profil cible, alors qu'ils devront être lus depuis la campagne.
:robot: Solution
Éviter de lire le profil cible pour obtenir les acquis.
Lire directement les acquis de la campagne en passant par le CampaignRepository
.
:rainbow: Remarques
Les méthodes get
et getByCampaignId
du TargetProfileRepository
ne renvoient plus les acquis.
:100: Pour tester
Les use cases impactés :
-
correctAnswerThenUpdateAssessment
-
getCampaignAssessmentParticipation
-
getCertificationCandidateSubscription
-
getNextChallengeForCampaignAssessment
-
getProgression
-
getUserCertificationEligibility
-
handleBadgeAcquisition
-
resetScorecard
-
retrieveLastOrCreateCertificationCourse
Les domains events handlePoleEmploiParticipation*
sont également impactés.
Le script computePoleEmploiSendings
est également impacté.
I'm deploying this PR to these urls:
- App (.fr): https://app-pr4887.review.pix.fr
- App (.org): https://app-pr4887.review.pix.org
- Orga: https://orga-pr4887.review.pix.fr
- Certif: https://certif-pr4887.review.pix.fr
- Admin: https://admin-pr4887.review.pix.fr
- API: https://api-pr4887.review.pix.fr/api/
Please check it out!
On a introduit une modification de comportement sur le endpoint /user/{id}/is-certifiable
.
Ce endpoint liste notamment les certifications complémentaires pour lesquelles l'utilisateur est éligible ; et pour cela il s'appuie sur les badges acquis par l'utilisateur (voir le usecase get-user-certification-eligibility)
Dans la table badge-acquisitions
, on a 653 lignes (créées en 2020) sur ~3 millions qui n'ont pas de campaignParticipationId
, et on se base maintenant sur cette colonne pour récupérer l'identifiant de la campagne, puis les acquis de cette campagne...
Donc les utilisateurs concernés par ces 653 lignes ne seront plus considérés comme éligibles aux certifications complémentaires correspondant à ces badge acquis sans campaignParticipationId
!
À voir avec team certif ?
Je comprend pas pourquoi les acquis sont plus dans le targetProfile, LA en terme de facto ce que je ferais c'est faire en sorte que les acquis soit dans le model targetProfile qui est est utilisé dans les use cases du scope prescription et j'aurais juste changer la requête dans le repo J'ai du mal à comprend l'objectif de la PR du coup.
Pourquoi on veut pas passer par le profile cible pour avoir les acquis, c'est quelque chose qui a du sens dans notre scope et qui représente bien le fonctionnel.