Informer les gestionnaires par mail des contenus en attente de validation.
Créer une entrée cron activable par paramétrage de l'appli, (cf ContentService avec les entrées @Scheduled), à faire tourner toutes les 4h. Qui pour chaque contexte va regarder si les notifications sont activées et effectuer un mail à l'ensemble ayant droits (Attention ne pas notifier les admin, mais normalement ils ne sont pas référencés).
Il ne faut notifier qu'une fois par jour et se baser sur la date de modification de l'actu pour ne pas la considérer comme à notifier à chaque fois que la tâche tourne (notifier si timeModification + temp entre deux exécutions tâche est > dateExecution - temps entre deux tâche). Et autre tâche scheduled < 24h à faire tourner 1 fois par jour durant la nuit pour notifier à nouveau des contenus en attente de validation.
Si aucun Manager et qu'il y a des contenus en Pending, notifier l'admin qu'aucun manager n'est défini sur telle organization et qu'il y a des contenus en pending.
Le plus simple serait peut-être de calculer les organisations ayant des itemStatus.Pending, puis de récupérer tous les manager des ctx publisher, puis des rubriques en lien avec les items avec ce status. Quand il s'agit d'un groupe faire appel à la méthode qui résout les membres des groupes (fusion données LDAP + BDD publisher) et en récupérer leur adresse mail (s'il n'ont pas désactivé les notifications - option du compte dans esup-publisher). Ne pas oublier les tests unitaire sur cette partie de récupération des infos avec différents cas de traitement.
Il y a déjà en place un système de template avec tymeleaf et avec les configs, cf MailService.java
Informer les gestionnaires par mail des contenus en attente de validation.
Créer une entrée cron activable par paramétrage de l'appli, (cf ContentService avec les entrées @Scheduled), à faire tourner toutes les 4h. Qui pour chaque contexte va regarder si les notifications sont activées et effectuer un mail à l'ensemble ayant droits (Attention ne pas notifier les admin, mais normalement ils ne sont pas référencés).
Il ne faut notifier qu'une fois par jour et se baser sur la date de modification de l'actu pour ne pas la considérer comme à notifier à chaque fois que la tâche tourne (notifier si timeModification + temp entre deux exécutions tâche est > dateExecution - temps entre deux tâche). Et autre tâche scheduled < 24h à faire tourner 1 fois par jour durant la nuit pour notifier à nouveau des contenus en attente de validation.
La notification doit se faire pour les contenus en attente de validation (ItemStatus.PENDING), avec envoi qu'une fois par jour, donc la création doit Il faut notifier les utilisateurs ayant la permission canEditCtx (les MANAGER, cf https://github.com/GIP-RECIA/esup-publisher/blob/main/src/main/java/org/esupportail/publisher/security/PermissionServiceImpl.java#L246).
Si aucun Manager et qu'il y a des contenus en Pending, notifier l'admin qu'aucun manager n'est défini sur telle organization et qu'il y a des contenus en pending.
Le plus simple serait peut-être de calculer les organisations ayant des itemStatus.Pending, puis de récupérer tous les manager des ctx publisher, puis des rubriques en lien avec les items avec ce status. Quand il s'agit d'un groupe faire appel à la méthode qui résout les membres des groupes (fusion données LDAP + BDD publisher) et en récupérer leur adresse mail (s'il n'ont pas désactivé les notifications - option du compte dans esup-publisher). Ne pas oublier les tests unitaire sur cette partie de récupération des infos avec différents cas de traitement.
Il y a déjà en place un système de template avec tymeleaf et avec les configs, cf MailService.java