Accorder un badge personnalisé via l'API

[Discourse]

Les badges personnalisés que vous avez créés sur votre forum peuvent être attribués via l’API. C’est un excellent moyen de décerner des badges sans avoir à utiliser de requêtes SQL personnalisées.

Pour attribuer un badge via l’API, vous devez connaître le nom d’utilisateur de la personne à qui vous souhaitez attribuer le badge, ainsi que l’identifiant (ou le nom) du badge à attribuer. Vous devez également vous assurer d’avoir généré une clé API dans la section Admin > API > Clés de votre site (/admin/api/keys).

Trouver l’identifiant du badge

Vous pouvez obtenir l’identifiant du badge à partir de son URL. Accédez à la section Admin/Badges, puis cliquez sur le badge que vous souhaitez attribuer. L’URL ressemblera à ceci : https://forum.example.com/admin/badges/102. Le dernier chiffre de l’URL est l’identifiant du badge.

Effectuer l’appel API

Pour tester un appel API, vous pouvez essayer d’attribuer un badge en utilisant curl ou Postman. Voici comment j’attribue un badge depuis le terminal de mon ordinateur avec curl.

Tout d’abord, pour faciliter les choses, définissez une variable api_key :

 api_key=yourapikey

Ensuite, pour attribuer un badge d’identifiant 102 à l’utilisateur 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"

Au lieu de badge_id, vous pouvez également utiliser badge_name pour identifier le badge par son nom :

-F "badge_name=My Custom Badge"

Le paramètre reason est facultatif. Si vous le fournissez, il doit être défini sur l’URL d’un sujet ou d’un message de votre site.

Vous devriez recevoir une réponse JSON contenant des détails sur le badge et la date de son attribution.

[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)]

Voir aussi Create a custom badge with an image through the API, qui montre comment téléverser, et contient également un autre exemple d’attribution du badge (en python).

[smileBeda (Beda)]

Quelle est la raison pour laquelle cette méthode n’est pas décrite dans la documentation de l’API sur https://docs.discourse.org/ ?

Je n’ai pas pu la trouver là-bas.

[pfaffman (Jay Pfaffman)]

@smileBeda

Quelle est la raison pour laquelle cette méthode n’est pas décrite dans la documentation de l’API sur https://docs.discourse.org/ ?

Parce qu’il ne semble pas y avoir de personne responsable de la mise à jour complète ou à jour de ces documents et qu’une âme charitable a publié ces instructions ici. En général, la documentation de l’API consiste à Ingénierie inverse de l’API Discourse et à examiner le code source.

[sunjam (james.network)]

Bien, il n’y a donc aucun moyen d’automatiser l’attribution de tels badges via une API ?

Par exemple, une personne qui reçoit 5 000 mentions « J’aime » sur ses réponses se voit attribuer un badge.

[pfaffman (Jay Pfaffman)]

@sunjam

quelqu’un qui reçoit 5 000 mentions J’aime sur ses réponses se voit attribuer un badge.

Si vous êtes auto-hébergé ou sur Enterprise, vous voulez Activer le SQL de badge.

[simon]

@sunjam

quelqu’un qui reçoit 5 000 likes sur ses réponses se voit attribuer un badge.

Si vous ne pouvez pas activer le badge SQL, il serait techniquement possible d’automatiser cela, mais ce serait un processus en deux étapes. Tout d’abord, effectuez une requête API pour exécuter une requête Data Explorer qui renvoie les noms d’utilisateur des utilisateurs qui répondent à vos critères et qui n’ont pas encore reçu le badge : Exécuter des requêtes Data Explorer avec l’API Discourse. Ensuite, utilisez les noms d’utilisateur renvoyés par cette requête pour attribuer le badge via l’API.

Cela semble un peu inefficace cependant. D’après ce que je peux dire, il n’y a pas de route qui puisse être utilisée pour attribuer un badge à plusieurs utilisateurs en un seul appel API, donc en fonction du nombre d’utilisateurs éligibles au badge, vous pourriez finir par effectuer de nombreuses requêtes API.

En fin de compte, cela ressemble au genre de chose qui pourrait être gérée par le plugin Automation. Il pourrait y avoir un déclencheur récurrent qui exécute une requête Data Explorer avec un identifiant de requête donné. En fonction des champs renvoyés par la requête, les résultats pourraient être utilisés pour déclencher divers scripts. Par exemple, si un champ username était renvoyé par la requête, il pourrait être utilisé pour exécuter des scripts qui attribuent des badges, ajoutent des utilisateurs à des groupes, etc.

[pfaffman (Jay Pfaffman)]

@simon

Il pourrait y avoir un déclencheur récurrent qui exécute une requête Data Explorer avec un ID de requête donné.

Cela n’aura pas les mêmes problèmes qui ont entraîné la désactivation du SQL des badges en premier lieu ?

[simon]

Je ne pense pas. Les requêtes de l’Explorateur de données sont exécutées dans un bloc de transaction qui expire après 10 secondes. Je pense que le but est d’éviter le type de problème que les requêtes de badges peuvent déclencher. Si les choses n’étaient pas configurées ainsi, une requête inefficace de l’Explorateur de données pourrait planter le site.

En y réfléchissant maintenant, je me demande si le SQL de badge personnalisé pourrait avoir le même type de protection.