feat(api): add notification for comment on obs

[mvergez]

Dans le cadre d'une prestation pour l'Agence Régionale de la Biodiversité Ile De France : ajout d'une notification lorsqu'un commentaire est ajouté sur l'observation d'un utilisateur.
La notification n'est pas envoyé aux utilisateurs commentant une observation qui n'ont pas faite.

Code de la notification : VALIDATION-NEW-COMMENT
Template de mail :

<p>Bonjour <i>{{ role.nom_complet }}</i> !</p> 
<p>Votre observation de l'espèce : {{ synthese.nom_cite }} du {{ synthese.meta_create_date.strftime('%d-%m-%Y') }} a reçu un commentaire</p>
<p>Vous pouvez y accéder directement <a href="{{ url }}">ici</a></p>
<p><i>Vous recevez cet email automatiquement via le service de notification de GeoNature.</i></p>

Template de notification :

Vous avez reçu un nouveau commentaire sur votre observation de {{ synthese.nom_cite }} du {{ synthese.meta_create_date.strftime('%d-%m-%Y') }}

Closes #2460

[codecov]

Codecov Report

Patch coverage: 93.33% and no project coverage change.

Comparison is base (f63581e) 69.07% compared to head (b8ea247) 69.07%.

❗ Current head b8ea247 differs from pull request most recent head 23bcca1. Consider uploading reports for the commit 23bcca1 to get more accurate results

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #2461   +/-   ##
========================================
  Coverage    69.07%   69.07%           
========================================
  Files           83       82    -1     
  Lines         7175     7163   -12     
========================================
- Hits          4956     4948    -8     
+ Misses        2219     2215    -4     

Flag	Coverage Δ
pytest	69.07% <93.33%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
backend/geonature/core/gn_synthese/routes.py	80.76% <93.33%> (+0.30%)	⬆️

... and 8 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[camillemonchicourt]

Je pense qu'il faut renommer la notification OBSERVATION-COMMENT car ce n'est pas spécialement lié à la validation.

Et ça me semble un peu partiel si celui qui commente n'est pas notifié en cas de réponse.

[DonovanMaillard]

Je pense qu'il faut renommer la notification OBSERVATION-COMMENT car ce n'est pas spécialement lié à la validation.

Et ça me semble un peu partiel si celui qui commente n'est pas notifié en cas de réponse.

Oui, en toute logique, il faut notifier le digitiser + tous ceux qui ont contribué aux commentaires sur l'observation en question, pour faciliter les échanges

[DonovanMaillard]

Vous avez reçu un nouveau commentaire sur votre observation de {{ synthese.nom_cite }} du {{ synthese.meta_create_date.strftime('%d-%m-%Y') }}

C'est assez ambigu comme message. Soit c'est "votre observation de [nom cité] du + date_début, soit c'est votre observation saisie le ...

Je privilégierais la 1ère option, et je sais pas si ca serait pas intéressant de remettre aussi la commune pour mieux resituer la donnée en question. Idem, ca peut etre intéressant dans la notification de savoir de qui vient le commentaire.

[Tel utilisateur] a commenté votre observation de {{ synthese.nom_cite }} du {{ synthese.date_min.strftime('%d-%m-%Y') à [la ou les communes] }}

[mvergez]

Salut @DonovanMaillard !

Merci beaucoup pour tous tes retours !

Oui, en toute logique, il faut notifier le digitiser + tous ceux qui ont contribué aux commentaires sur l'observation en question, pour faciliter les échanges

Oui je suis d'accord, mais je pense que ça doit être fait en 2 temps. Car en regardant un peu le code il faudrait, à chaque POST de commentaire, faire un requête pour accéder à tous les commentaires de l'observation. Cela peut-être un peu lourd... Il faudrait je pense réfléchir à un meilleur moyen. Via peut-être le frontend qui récupère déjà tous les commentaires... A réfléchir mais ce n'est pas l'objectif de la PR et la demande formulée, donc à faire dans une autre PR à mon sens.

C'est assez ambigu comme message. Soit c'est "votre observation de [nom cité] du + date_début, soit c'est votre observation saisie le ...

Je crois que j'ai mal compris ta remarque puisqu'au final on partirait sur : [Tel utilisateur] a commenté votre observation de {{ synthese.nom_cite }} du {{ synthese.date_min.strftime('%d-%m-%Y'). Ce qui est assez similaire à ce que j'avais proposé non ?

Pour la commune, bonne idée aussi mais cela fait rajouter une jointure à la query, est-ce nécessaire ? Beaucoup d'observations à la même date peuvent-elles être dans 2 communes séparées ? Sachant qu'on entre un point précis ou une géométrie plutôt qu'une commune, donc on n'a pas forcément l'information si on n'a pas regardé notre observation a posteriori (par exemple si on saisit via occtax mobile) ?

Ok pourquoi pas pour l'utilisateur, je vais regarder ce qu'il est possible de faire.

Merci en tout cas pour tes suggestions !

[camillemonchicourt]

Je rejoins @DonovanMaillard, la date de l'observation est mieux que la date de saisie, qui peuvent en effet être bien différents.
Pour l'ajout de la commune, c'est un plus mais pas essentiel selon moi. Ça permet de mieux identifier ce dont il s'agit dès réception de la notification.

[mvergez]

Yes je suis d'accord aussi pour la date, du coup date_min ou date_max ?
C'est possible pour la commune mais la requête en vaut-elle la peine ? C'est pas grand chose c'est 2 jointures mais à voir

[DonovanMaillard]

Je crois que j'ai mal compris ta remarque puisqu'au final on partirait sur : [Tel utilisateur] a commenté votre observation de {{ synthese.nom_cite }} du {{ synthese.date_min.strftime('%d-%m-%Y').

C'est justement la date qui différait, j'avais pris date_min ;) A mon sens date min, dans tous les cas on ne vas pas mettre les 2, et c'est souvent un jour + son lendemain pour des observations de nuit. Donc date_min reste pertinent je pense.

Pour les communes si ca vient rajouter trop de jointures etc, c'est un plus mais pas indispensable donc ça justifie pas de ralentir et alourdir le mécanisme. Par contre récupérer tous les commentateurs d'une donnée me semble essentiel.

A fait une donnée, B fait une remarque, A répond -> B n'est pas informé, ça laisse peu d'intérêt et je vois déjà les mails arriver pour me signaler un bug :)

[mvergez]

Ok top merci @DonovanMaillard ! Je vais regarder pour les commentaires et réfléchir au meilleur moyen de le faire :) Je le proposerai dans cette PR

[camillemonchicourt]

Suite aux différents échanges, @mvergez a élargi le périmètre fonctionnel de cette fonctionnalité et fait en sorte de notifier aussi les observateurs (sans doublonner si le digitiser est aussi observateur), mais aussi les commentateurs de l'observation :

• Si "admin" fait une obs avec "agent" et que "validateur" commente : "agent" et "admin" sont prévenus
• Si "admin" rajoute un commentaire : "agent" et "validateur" sont prévenus

[DonovanMaillard]

Suite aux différents échanges, @mvergez a élargi le périmètre fonctionnel de cette fonctionnalité et fait en sorte de notifier aussi les observateurs (sans doublonner si le digitiser est aussi observateur), mais aussi les commentateurs de l'observation :

* Si "admin" fait une obs avec "agent" et que "validateur" commente : "agent" et "admin" sont prévenus

* Si "admin" rajoute un commentaire : "agent" et "validateur" sont prévenus

parfait, merci @mvergez :)

[camillemonchicourt]

Révision des messages de notification, suite à l'ajout de la notification des commentateurs.

[bouttier]

Attention en mergeant à la révision alembic