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

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 ?

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)

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 ?

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 :-)

une discussion sur un jeu de données qui pointe vers transport.data.gouv.fr

merci pour l'ouverture 😻🚌🚊