Vitrine et upsell apprenants

Version métier : voir Vitrine et upsell apprenants.

Description

Commande quotidienne qui, pour chaque apprenant ayant au moins une session sur l’année active, recalcule :

1. la liste des produits recommandés (affichés dans son espace comme propositions de formations complémentaires à la vente — upsell) ;
2. le produit mis en avant (showcase) — unique produit choisi selon un jeu de règles métier (vitrine publique visible côté site erevo).

Les deux valeurs sont matérialisées en base pour éviter le recalcul à chaque requête HTTP.

Déclenchement

Planification GitLab (via pipeline_schedules API, 2026-04-23) :

• Description : Setup recommended products & showcase
• ID du schedule : 4086440
• Cron : 0 1 * * * (fuseau : Europe/Paris) — 01:00 Paris chaque jour.
• Branche : refs/heads/master
• État : actif
• Variable injectée : SCHEDULE_TYPE=student_showcase_recommended_products

Job CI : setup_student_showcase dans ci-jobs/.scheduled-ci.yml (stage setup_student_showcase).

Commande exécutée :

docker exec $APP_NAME php bin/console scheduled:student-show-case-recommended

Fonctionnement

1. StudentRepository::getStudentThatHaveASessionInActiveYear() renvoie les apprenants éligibles (au moins une Session sur l’année scolaire active).
2. StudentService::setRecommendedProductsForStudents($students) met à jour la collection recommendedProducts de chaque apprenant — ces produits sont les upsells proposés à la vente dans son espace.
3. Seconde passe : StudentService::setShowCase($students) applique les règles de sélection (dans l’ordre) pour choisir le produit showcase (vitrine publique) :
   • « case one » — priorité la plus forte ;
   • sinon « case two » ;
   • sinon « case three » ;
   • sinon, tirage aléatoire parmi les produits recommandés ;
   • sinon, fallback sur un produit aléatoire disponible.
4. EntityManager::flush() pour persister les deux passes.

TODO(review) : documenter précisément les critères métier derrière « case one / two / three » de StudentService::setShowCase() (lire src/Service/StudentService.php autour de la méthode).

Entités impactées

• Student — écriture de showCase (ManyToOne Product) et de la collection recommendedProducts.
• Product — lecture seule.
• Session — lecture via getStudentThatHaveASessionInActiveYear() pour filtrer les apprenants actifs.

TODO(review) : pages modele-de-donnees/student, modele-de-donnees/product et modele-de-donnees/session absentes — à créer par entity-documenter.

Gestion des erreurs

• Aucune exception dédiée. Une erreur DB / Doctrine remonte dans Sentry et fait échouer le job GitLab.
• Le flush() final est atomique ; en cas d’échec, aucune des modifications calculées n’est persistée.

Dépendances externes

Aucune API tierce. Commande 100 % DB / MariaDB.

Observabilité

• Logs : GitLab > Build > Pipelines > setup_student_showcase — trois lignes de sortie (Setting up student recommended products, Setting up student show case, Flushing).
• Alerting : Sentry capture les exceptions PHP.

Références code

• Commande : src/Command/Scheduled/SetupShowCaseAndRecommendedProductCommand.php
• Job CI : ci-jobs/.scheduled-ci.yml (job setup_student_showcase)
• Services : App\Service\StudentService::setRecommendedProductsForStudents(), StudentService::setShowCase()
• Repository : App\Repository\StudentRepository::getStudentThatHaveASessionInActiveYear()