Ce document liste les conditions qui declenchent la creation d'une notification BO (table notif) dans DEMA1N.

Portee

• Type de notification: notifications internes BO (pas les emails/SMS transactionnels).
• Source technique: appels a createNotif(...) dans back/src/binomes/services/notif.service.ts.

Regles generales de reception

• Une notification est "recue" par l'admin dont l'ID est passe en 3e argument de createNotif(..., adminId, ...).
• Aucune logique d'opt-in / newsletter n'est appliquee sur ces notifs BO.
• Une notif est consideree "non lue" quand le champ read est NULL.

Cas de creation de notifications

1) assigner-jeune

• Declencheur: appel PUT /jeune/associate.
• Contexte: un jeune est assigne a un admin.
• Conditions metier:
• l'utilisateur qui assigne est superadmin ou admin (guard de route),
• si l'utilisateur qui assigne est admin, il doit avoir l'option manager,
• l'utilisateur cible (adminId) doit avoir le profil admin.
• Destinataire de la notif: l'admin cible (adminId).
• Description stockee: "<Prenom> <Nom> t'a ete assigne".
• Code:
• back/src/binomes/controllers/jeune.controller.ts (associateJeune)

2) vol-jeune

• Declencheur: changement de suivi admin d'un jeune via changeAdminJeuneAndBinomeAndBenevole(...).
• Contexte: un admin "reprend" un jeune deja suivi.
• Condition exacte:
• jeune.adminId existe
• et jeune.adminId !== adminId (nouvel admin different de l'actuel).
• Destinataire de la notif: l'ancien admin du jeune (jeune.adminId).
• Description stockee: "<Prenom nouvel admin> a suivi le jeune <Prenom jeune> <Nom jeune>".
• Code:
• back/src/binomes/services/jeunes.service.ts (changeAdminJeuneAndBinomeAndBenevole)

3) vol-mentor

• Declencheur: changement d'admin associe d'un mentor via changeAdminAssocieBenevoleAndBinomesAndJeunes(...).
• Contexte: un admin "reprend" un mentor deja suivi.
• Condition exacte:
• benevole.adminAssocieId existe
• et benevole.adminAssocieId !== adminId (nouvel admin different de l'actuel).
• Destinataire de la notif: l'ancien admin associe du mentor (benevole.adminAssocieId).
• Description stockee: "<Prenom nouvel admin> a suivi le mentor <Prenom mentor> <Nom mentor>".
• Code:
• back/src/binomes/services/benevoles.service.ts (changeAdminAssocieBenevoleAndBinomesAndJeunes)

4) jeune-apte (cron)

• Declencheur: cron quotidien.
• Horaire cron: 23:45 (expression 0 45 23 * * *).
• Condition d'execution worker: WORKER_SERVER === '1'.
• Contexte: alerte BO pour les jeunes en attente de matching.
• Conditions de selection des jeunes:
• status = 'APTE'
• statusUpdateDate entre J-6 et J-5
• adminId non null
• Destinataire de la notif: l'admin du jeune (jeune.adminId).
• Description stockee: "<Prenom jeune> <Nom jeune> attend d'etre matche depuis 5 jours".
• Code:
• back/src/binomes/services/cron-tasks.service.ts (notifyJeuneApte)
• back/src/binomes/services/jeunes.service.ts (notifyJeuneApte)

5) binome-refuse

• Declencheur: un binome passe au statut REFUSE et le mentor repasse en APTE.
• Contexte: mentors EP (badge partenaire) uniquement. Ils conservent leur adminAssocieId apres un refus ; l'admin associe est prevenu qu'il peut matcher a nouveau ce mentor.
• Condition exacte (verifiee dans BinomeService.notifyBinomeRefuseToAdminAssocie):
• binome.status === 'REFUSE' (et non pas ANNULE) ;
• apres mise a jour, benevole.status === 'APTE' ;
• benevole.badges contient 'partenaire' ;
• benevole.adminAssocieId est defini.
• Destinataire de la notif: l'admin associe du mentor (benevole.adminAssocieId).
• Description stockee: "<Prenom mentor> <Nom mentor> est de nouveau disponible car son binôme a été refusé par le jeune, tu peux le matcher à nouveau".
• Cible du clic: fiche mentor /bo/benevoles/{{benevoleId}} (slug mappe dans front/static/model/NotifList.js).
• Cas couverts (tous types de binomes : matching instantane, manuel, classique) :
• Multiselection (double proposition jeune) : quand le jeune accepte une des propositions, l'autre (alternative) passe REFUSE et son mentor repasse APTE.
  • BinomeService.premerBinome (acceptation cote jeune).
  • BinomeService.editBinome (passage du principal depuis EN_ATTENTE_JEUNE).
  • BinomeService.terminateBinome (terminaison forcee du principal encore en EN_ATTENTE_JEUNE).
  • BinomeService.cancelBinome branche alternative (refus cote jeune avec double proposition).
• Multiselection BO (annulation/terminaison en lot) : BinomeService.cancelBinomes et BinomeService.terminateBinomes iterent respectivement sur cancelBinome et terminateBinome. La notif est donc emise une fois par binome eligible (mentor EP qui repasse APTE apres REFUSE).
• Fin des 48h (cron) : BinomeService.cancelBinomePremer → BinomeService.cancelBinome (expiration de la duree de reponse du jeune, par defaut 3 jours via partner.options.durationPremer).
• Refus a la main : appel direct de BinomeService.cancelBinome sur un binome EN_ATTENTE_JEUNE (depuis le BO ou les endpoints reponse).
• Suppression du compte LY : UsersService.quitAllBinomes appelle BinomeService.cancelOneBinome, qui passe le binome en ANNULE (et non REFUSE). Le mentor repasse bien APTE, mais la notification n'est pas emise pour ce cas (condition "pas annule" respectee).
• Cas non concernes :
• BinomeService.changeStatusBinome (et son pendant bulk changeStatutsMultiple) modifie uniquement le champ status du binome sans toucher au statut du mentor : le mentor ne repasse pas automatiquement APTE, donc la notif n'a pas lieu d'etre (le garde-fou benevole.status === 'APTE' dans le helper filtre de toute facon).
• Code:
• back/src/binomes/services/binomes.service.ts (notifyBinomeRefuseToAdminAssocie, appele dans cancelBinome, cancelBinomeNonDispo, terminateBinome, editBinome, premerBinome).

Recapitulatif rapide

Notes

• Les emails/SMS transactionnels sont geres ailleurs (notamment NotificationService) et ne sont pas inclus dans cette doc.
• Si besoin, faire une doc separee "emails/SMS - conditions de declenchement".