Notification à l'ouverture d'un commentaire sur un bouquet

martyKN commented 1 week ago

Lorsque un user commente un bouquet, l'owner du bouquet ne reçoit pas de notification. Est de possible, à l'image d'un commentaire sur un jdd sur dgfr, que le owner d'un bouquet reçoive une notification par mail quant à la publication d'un commentaire sur un bouquet. SDans le cas où le bouquet est owned par une orga, alors tous les users de l'orga reçoivent la notif lorsque un nouveau commentaire est fait dans la discussion, l'ensemble des personnes ayant aussi commenté recoivent une notification

abulte commented 1 week ago

Point d'entrée https://github.com/opendatateam/udata/blob/b472b9c1482128471558ee92ceae1274d6aaaf36/udata/core/discussions/tasks.py#L28

abulte commented 1 week ago

Pas si simple parce qu'il va falloir contrôler la manière dont udata :

affiche le nom du modèle : topic vs bouquet
calcule l'URL vers laquelle renvoie la notification, pour renvoyer sur Ecosphères

Pour référence, un screenshot d'une notification sur un jeu de données ci-dessous.

Peut-être étendre le schéma des extras d'un bouquet avec quelque chose comme :

"meta": {
  "notifications": {
    "model_name": "bouquet",
    "external_url": "https://ecologie.data.gouv.fr/bouquets/{slug}/"
  }
}

Ainsi on peut utiliser ces informations si elles existent lors de la notification dans udata.

Autre possibilité : utiliser les extras de la discussion pour porter le même payload. C'est une approche plus souple parce que :

On peut imaginer d'autres usages sur d'autres modèles que Topic (e.g. une discussion sur un jeu de données qui pointe vers transport.data.gouv.fr)
On écrit le payload au moment de la création de la discussion plutôt qu'au moment de créer l'objet sur lequel porte la discussion. On peut ainsi changer de comportement sans migration des modèles de base. On a aussi une traçabilité par discussion de quelle notification a été déclenchée selon quelles règles.

Dans tous les cas, il faudra certainement prévoir une accept list pour les domaines vers lesquels peuvent pointer external_url, sinon on s'expose à des détournements possibles pour envoyer des notifications avec des liens vers des domaines tiers.

WDYT @streino @geoffreyaldebert @ThibaudDauce @maudetes ?

ThibaudDauce commented 1 week ago

Personnellement j'aime bien l'idée, je pense que la 2e option est préférable effectivement ça permet de ne pas lier ça au sujet et plutôt à où été posté le message (si le message est posté depuis data.gouv on notifie sur data.gouv, si c'est publié sur transport on notifie sur transport, si c'est ecospheres on notifie avec des liens vers ecospheres…).

Si c'est validé, ça peut être fait rapidement je pense (c'est pas un gros changement si on utilise les extras)

streino commented 1 week ago

La 2e solution me semble aussi plus souple.

model_name me semble moins critique mais pourquoi pas. On pourrait se contenter de "X submitted a new discussion on URL". Les messages de notifs sont forcément en anglais ou model_name devra s'adapter ?

Question de newb : L'accept-list pourrait-elle être liée aux domaines whitelistés pour l'auth ?

abulte commented 1 week ago

Les messages sont traduits mais comme on ne traduit pas bouquet généralement pas de problème 😇. Parce que ce serait un peu relou de traduire sans avoir la chaine source dans le code de udata... Moins critique en effet mais comme la string actuelle porte le nom du modèle, autant rester là-dessus je pense.

Pour l'auth j'y ai pensé mais ça m'étonnerait, je ne pense pas qu'on puisse savoir facilement d'où vient l'authentification du user courant.

@ThibaudDauce je vais faire une PR là-dessus semaine pro :-)

ecolabdata / ecospheres

Notification à l'ouverture d'un commentaire sur un bouquet #263