Obtenir l'utilisateur cible pour les événements de webhook de notification

Je constate que les webhooks prennent désormais en charge les notifications, ce qui est fantastique. C’est exactement ce dont nous avions besoin. Cependant, le payload manque d’une information cruciale : l’utilisateur concerné par la notification. Dans l’exemple de payload ci-dessous, nous pouvons voir l’auteur du post ayant déclenché la notification, mais pas l’utilisateur qui devrait la recevoir.

{
  "notification": {
    "id": 119,
    "notification_type": 9,
    "read": false,
    "created_at": "2019-09-18T13:42:21.248Z",
    "post_number": 1,
    "topic_id": 75,
    "fancy_title": "Phallguy devrait recevoir un avis à ce sujet",
    "slug": "phallguy-should-get-a-notice-about-this",
    "data": {
      "topic_title": "Phallguy devrait recevoir un avis à ce sujet",
      "original_post_id": 111,
      "original_post_type": 1,
      "original_username": "Paul_Alexander",
      "revision_number": null,
      "display_username": "Paul_Alexander"
    }
  }
}

J’ai cherché s’il existait une API permettant de récupérer l’utilisateur cible à partir de l’ID de notification, mais je n’ai rien trouvé de documenté. Y a-t-il un moyen d’obtenir le nom d’utilisateur ou l’ID de l’utilisateur cible dans le payload de la notification ?

Pour contexte, nous essayons de regrouper les notifications provenant de plusieurs systèmes en une expérience unique pour nos utilisateurs.

@Falco ou @blake, avez-vous des idées sur la manière de déterminer quel utilisateur concerne une notification lorsqu’elle est reçue via le nouveau webhook de notification ?

J’ai jeté un coup d’œil rapide pour voir s’il y avait une réponse rapide, et vous avez raison : il ne semble pas que nous ayons un point de terminaison d’API get pour récupérer une notification individuelle par son ID. De toute façon, ce ne serait pas très efficace de l’appeler à chaque fois.

Il faudra probablement modifier le code du sérialiseur de notifications pour inclure l’user_id/username dans la charge utile de la notification, afin d’éviter une requête API supplémentaire.

Nous utilisons actuellement le service hébergé, sinon je créerais mon propre plugin. Seriez-vous prêts à ajouter l’ID utilisateur ou le nom d’utilisateur au contenu de la notification dans le webhook ?

Avez-vous vérifié les en-têtes ?

Je l’ai fait, en espérant trouver des métadonnées supplémentaires, mais je n’ai rien trouvé de spécifique à l’utilisateur.

URL de la requête : https://XXX
Méthode de la requête : POST
Accept : */*
Connection : close
Content-Length : 420
Content-Type : application/json
Host : XXX
User-Agent : Discourse/2.4.0.beta4
X-Discourse-Instance : https://XXX
X-Discourse-Event-Id : 11
X-Discourse-Event-Type : notification
X-Discourse-Event : notification_created
X-Discourse-Event-Signature : sha256=XXX

Je me permets de revenir vers vous pour savoir si vous avez des idées ou des mises à jour. Le webhook de notification sans utilisateur cible n’est pas très utile.

Salut les gars, avez-vous eu l’occasion de passer en revue le problème ? Y a-t-il une chance que nous puissions obtenir l’ID utilisateur cible dans l’événement de notification ?

J’ai créé une PR qui ajoutera le user_id au payload JSON du webhook de notification :

Bonjour @blake, serait-il possible d’ajouter également l’external_id de l’utilisateur ? Nous utilisons le SSO de Discourse et nous n’avons pas vraiment les identifiants d’utilisateur Discourse dans notre système.

Bonjour Albert !

Je pense que c’est une bonne idée, et j’ai créé un commit qui ajoutera l’external_id de l’utilisateur si le SSO est activé.

J’espère que cela t’aidera ! Cela sera ajouté à ton site lors de la prochaine déploiement, ce qui devrait avoir lieu cette semaine.

Wow, c’était rapide ! Merci beaucoup, c’est vraiment apprécié :smiley: Savez-vous quel est l’ETA approximatif pour que ces modifications soient déployées sur les serveurs Discourse hébergés ?

Oh, peu importe, je n’ai pas lu la dernière phrase :sweat_smile:. Merci encore !!