Peut-on inclure les noms d'utilisateur dans la charge utile du webhook user_badge ?

Soutien
,
1

Y a-t-il une possibilité que les webhooks user_badge incluent username en plus de user_id ? Actuellement, la charge utile pour un événement user_badge ressemble à ceci :

{
  "user_badge": {
    "id": 123456,
    "granted_at": "2026-09-25T14:54:42.073Z",
    "created_at": "2026-09-26T05:34:12.965Z",
    "post_id": 234567,
    "post_number": 1,
    "badge_id": 123,
    "user_id": 456,
    "granted_by_id": -1,
    "topic_id": 56789
  }
}

Obtenir le nom d’utilisateur pour un user_id (et granted_by_id s’il n’est pas égal à -1) nécessite un appel supplémentaire à /admin/users/{user_id}.json, ce qui non seulement requiert des requêtes supplémentaires, mais nécessite également des privilèges d’administrateur, si je ne m’abuse.

Y a-t-il un moyen d’obtenir le username pour un user_id donné en utilisant une clé API sans avoir besoin de privilèges d’administrateur ?

Je crée un service externe que j’espérais déclencher lorsqu’un ou plusieurs badges spécifiques sont attribués ; cependant, il a besoin du nom d’utilisateur et les webhooks de badges ne renvoient que des identifiants d’utilisateur. :confused:

2

Pour information, ma solution de contournement pour les webhooks non standard ou lorsque j’ai besoin de données supplémentaires consiste à le faire via Workflows et d’envoyer ceci à n8n.

3

Pour information, récupérer le nom d’utilisateur à partir de l’identifiant n’est qu’à un appel d’API. À moins que vous n’attribuiez manuellement des milliers de badges instantanément, vous devriez être dans les limites par défaut de l’API.

4

Merci ! Je vais jeter un œil à Workflows.

5

C’est une excellente nouvelle ! Pourriez-vous s’il vous plaît fournir des détails sur cet appel API qui n’est pas /admin/users/{user_id}.json (lequel nécessite des privilèges d’administrateur) ? Je n’ai pas réussi à trouver un point d’accès permettant de le faire avec une clé API sans privilèges d’administrateur.

6

Quel est le problème avec une clé API d’admin ? C’est censé être un tâche en arrière-plan, non ?

7

Le principe du moindre privilège. Ce service externe sera exécuté sur un autre serveur et n’a besoin que d’un accès en lecture à Discourse pour effectuer son travail. Moins il y a de clés maîtresses qui circulent dans l’infrastructure, mieux c’est.

8

Cela soulève le point intéressant de savoir pourquoi il n’existe pas de point d’accès public permettant de récupérer un utilisateur par son identifiant, en ne montrant que les champs publics, lorsque login_required n’est pas sélectionné. Cela serait utile, non ? Je me demande pourquoi cela n’a pas été mis en place. Ou peut-être que seuls les utilisateurs connectés peuvent bénéficier de ce privilège, mais dans tous les cas, il devrait exister un moyen d’y accéder sans recourir au point d’accès administrateur…

@burke Une solution de contournement plus fastidieuse consisterait à consulter /groups/trust_level_0/members.json (ou un groupe plus spécifique) et à trouver l’utilisateur par son identifiant, car cette page contient également le nom d’utilisateur.