Conceda uma insígnia personalizada através da API

[Discourse]

Badges personalizados que você criou no seu fórum podem ser concedidos por meio da API. Essa é uma ótima maneira de distribuir badges sem precisar usar SQL de badges personalizados.

Para conceder um badge via API, você precisa saber o nome de usuário do usuário ao qual deseja conceder o badge e o ID (ou nome) do badge que deseja conceder. Além disso, certifique-se de ter gerado uma chave de API na seção Admin > API > Chaves do seu site (/admin/api/keys).

Encontrando o ID do Badge

Você pode obter o ID do badge a partir da URL dele. Acesse a seção Admin/Badges e clique no badge que deseja conceder. A URL se parecerá com algo assim: https://forum.example.com/admin/badges/102. O último número na URL é o ID do badge.

Fazendo a chamada da API

Para testar uma chamada de API, você pode tentar conceder um badge usando curl ou Postman. Veja como concedo um badge do terminal do meu computador com curl.

Primeiro, para facilitar as coisas, defina uma variável api_key:

api_key=sua_chave_api

Em seguida, para conceder um badge com o ID 102 ao usuário bobby:

curl -X POST "https://forum.example.com/user_badges" \
-H "Api-Key: $api_key" \
-H "Api-Username: system" \
-F "username=bobby" \
-F "badge_id=102" \
-F "reason=https://forum.example.com/t/whats-the-best-photo-youve-ever-taken/160/2"

Em vez de badge_id, você também pode usar badge_name para identificar o badge pelo seu nome:

-F "badge_name=Meu Badge Personalizado"

O parâmetro reason é opcional. Se você o fornecer, ele deve ser definido como a URL de um tópico ou de uma postagem no seu site.

Você deverá receber uma resposta JSON com detalhes sobre o badge e quando ele foi concedido.

[jtbayly]

Has anybody added a badge (or flair) via Zapier to Discourse API like outlined here?

Trigger a Zapier task with Discourse Webhooks

[image] Want to use Discourse Webhooks to trigger a task via Zapier? Let’s get started! Zapier requires a trigger and an action. In this howto the trigger will be a Discourse Webhook and the action will be to send an email. Send an Email on any User event We will now set up a Zap to send email on any user event (i.e when a user is created, approved or updated). To trigger on a specific user event, see Trigger on a specific user event below. Create a Discourse Webhook Create a new Disco…

Also, seems like a great candidate for an action via the official integration, @HAWK.

[mattdm (Matthew Miller)]

Veja também Create a custom badge with an image through the API, que mostra como fazer upload e também tem outro exemplo de concessão do distintivo (em python).

[smileBeda (Beda)]

Qual é o motivo pelo qual este método não é descrito na documentação da API em https://docs.discourse.org/?

Não consegui encontrar isso lá.

[pfaffman (Jay Pfaffman)]

@smileBeda

Qual é o motivo pelo qual este método não é descrito na API Docs em https://docs.discourse.org/?

Porque não parece ser o trabalho de ninguém manter esses docs completos ou atualizados e alguma alma gentil postou estas instruções aqui. Geralmente, a documentação para a API é Engenharia reversa da API do Discourse e olhando o código fonte.

[sunjam (james.network)]

Legal, então não há como automatizar a concessão de um distintivo via API?

Por exemplo, alguém que recebe 5.000 curtidas em suas respostas ganha um distintivo.

[pfaffman (Jay Pfaffman)]

@sunjam

alguém que recebe 5.000 curtidas em suas respostas recebe um distintivo.

Se você estiver auto-hospedado ou no Enterprise, você vai querer Habilitar SQL de Distintivos.

[simon]

@sunjam

alguém que recebe 5.000 curtidas em suas respostas recebe um distintivo.

Se você não puder ativar o SQL de distintivos, seria tecnicamente possível automatizar isso, mas seria um processo de duas etapas. Primeiro, faça uma solicitação de API para executar uma consulta do Data Explorer que retorne os nomes de usuário dos usuários que atendem aos seus critérios e que ainda não receberam o distintivo: Executar consultas do Data Explorer com a API do Discourse. Em seguida, use os nomes de usuário retornados por essa consulta para conceder o distintivo por meio da API.

No entanto, isso parece meio ineficiente. Pelo que posso dizer, não há uma rota que possa ser usada para conceder um distintivo a vários usuários com uma única chamada de API, portanto, dependendo de quantos usuários se qualificam para o distintivo, você pode acabar fazendo muitas solicitações de API.

Em última análise, isso parece o tipo de coisa que poderia ser tratada pelo plugin de Automação. Poderia haver um gatilho recorrente que execute uma consulta do Data Explorer com um determinado ID de consulta. Com base nos campos retornados pela consulta, os resultados poderiam ser usados para acionar vários scripts. Por exemplo, se um campo username fosse retornado pela consulta, ele poderia ser usado para executar scripts que concederiam distintivos, adicionariam usuários a grupos, etc.

[pfaffman (Jay Pfaffman)]

@simon

Poderia haver um gatilho recorrente que executa uma consulta do Data Explorer com um determinado ID de consulta

Isso não terá os mesmos problemas que fizeram o SQL do distintivo ser desabilitado em primeiro lugar?

[simon]

Não acho. As consultas do Explorador de Dados são executadas em um bloco de transação que expira após 10 segundos. Acho que o objetivo disso é evitar o tipo de problema que as consultas de selos podem acionar. Se as coisas não estivessem configuradas dessa forma, uma consulta ineficiente do Explorador de Dados poderia travar o site.

Pensando nisso agora, me pergunto se o SQL de selos personalizado poderia ter o mesmo tipo de salvaguarda.