Можно ли добавить имена пользователей в webhook-запрос user_badge?

Поддержка
,
1

Есть ли шанс, что вебхуки user_badge могли бы включать username вместе с user_id? Сейчас полезная нагрузка (payload) для события user_badge выглядит так:

{
  "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
  }
}

Чтобы получить имя пользователя для user_id (и для granted_by_id, если он не равен -1), требуется дополнительный запрос к /admin/users/{user_id}.json. Это не только требует дополнительных запросов, но и, насколько я понимаю, требует прав администратора.

Есть ли способ получить username для заданного user_id с помощью API-ключа без необходимости в правах администратора?

Я создаю внешний сервис, который, как я надеялся, должен срабатывать при присвоении определенных значков; однако ему нужно имя пользователя, а вебхуки значков возвращают только идентификаторы пользователей. :confused:

2

К слову, моим обходным решением для нестандартных вебхуков или когда мне нужны дополнительные данные, является использование Workflows, а затем отправка именно их в n8n.

3

Кстати, получение имени пользователя по его ID — это всего один вызов API. Если вы не присваиваете тысячи значков вручную за один момент, стандартных лимитов API вам должно хватить.

4

Спасибо! Я посмотрю, как работают Workflows.

5

Это отличные новости! Не могли бы вы уточнить детали этого одного вызова API, который не является /admin/users/{user_id}.json (требующим прав администратора)? Я не смог найти эндпоинт, который позволял бы сделать это с помощью API-ключа без прав администратора.

6

В чём проблема с админ-ключом API? Это же, наверное, фоновая задача?

7

Принцип минимальных привилегий. Эта внешняя служба будет работать на другом сервере и нуждается только в доступе на чтение к Discourse для выполнения своей задачи. Чем меньше мастер-ключей курсирует по инфраструктуре, тем лучше.

8

Это поднимает интересный вопрос: почему нет публичного эндпоинта для получения пользователя по его ID, который отображал бы только публичные поля, если не выбран параметр login_required. Было бы полезно, не правда ли? Неужели это не сделали? Или, возможно, такая привилегия доступна только зарегистрированным пользователям, но в любом случае должен существовать способ получить к этому доступ без использования административного эндпоинта…

@burke Более обременительным обходным решением было бы обратиться к /groups/trust_level_0/members.json (или к любой более конкретной группе) и найти пользователя по его ID, поскольку там также содержится имя пользователя.

9

Это связано с тем, что пользовательские идентификаторы (user IDs) во всех случаях и для всех целей являются, по сути, внутренним соглашением в Discourse, и мы ожидаем, что вы будете полагаться на имена пользователей, которые значительно более распространены во всех отношениях.