I nomi utente potrebbero essere inclusi nel payload del webhook user_badge?

Supporto
,
1

C’è la possibilità che i webhook user_badge possano includere anche username oltre a user_id? Attualmente il payload per un evento user_badge ha questo aspetto:

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

Ottenerlo username per un dato user_id (e granted_by_id, se non è -1) richiede una chiamata aggiuntiva a /admin/users/{user_id}.json, il che non solo richiede richieste aggiuntive, ma anche privilegi di amministratore, almeno a quanto riesco a capire.

Esiste un modo per ottenere username per un dato user_id utilizzando una chiave API senza aver bisogno di privilegi di amministratore?

Sto creando un servizio esterno che speravo di attivare quando vengono concessi determinati badge; tuttavia, ha bisogno del nome utente e i webhook dei badge restituiscono solo gli ID utente. :confused:

2

Comunque, il mio workaround per webhook non standard o quando ho bisogno di dati aggiuntivi è farlo tramite Workflows e poi inviare quello a n8n.

3

Per la cronaca, recuperare il nome utente dall’ID utente richiede solo una chiamata API, a meno che tu non stia assegnando manualmente migliaia di badge in un istante, nel qual caso dovresti essere al sicuro con i limiti API predefiniti.

4

Grazie! Darò un’occhiata a Workflows.

5

Ottimo sentirlo! Potresti fornirmi i dettagli su quella singola chiamata API che non è /admin/users/{user_id}.json (che richiede privilegi di amministratore)? Non sono riuscito a trovare un endpoint per farlo con una chiave API che non richiedesse privilegi di amministratore.

6

Qual è il problema con una chiave API di amministrazione? Questo dovrebbe essere un job in background, giusto?

7

Principio del minimo privilegio. Questo servizio esterno verrà eseguito su un altro server e ha bisogno solo di accesso in lettura a Discourse per svolgere il suo compito. Meno chiavi master in giro tra le infrastrutture, meglio è.

8

Questo solleva un punto interessante: perché non esiste un endpoint pubblico per ottenere un utente tramite ID che mostri solo i campi pubblici, quando login_required non è selezionato? Sarebbe utile, no? Mi chiedo perché non sia stato implementato. Forse solo gli utenti autenticati possono avere questo privilegio, ma in ogni caso dovrebbe esserci un modo per accedervi senza utilizzare l’endpoint di amministrazione…

@burke Un workaround più impegnativo sarebbe quello di consultare /groups/trust_level_0/members.json (o un gruppo più specifico) e trovare l’utente tramite il suo ID, poiché anche questa endpoint contiene il nome utente.