Cela est-il lié au fait que l’API https://{defaultHost}/invites/link.json a cessé de fonctionner aujourd’hui ?
Je ne suis pas sûr – cela pourrait être le cas ? Je ne connais pas ce point de terminaison.
Eh bien, j’ai reçu plusieurs centaines d’e-mails indiquant que nos automatisations échouent désormais. Nous utilisions le point de terminaison https://{defaultHost}/invites/link, mais nous commençons à recevoir des erreurs 404. J’ai consulté la documentation, et il est maintenant indiqué que le point de terminaison est https://{defaultHost}/invites/link.json (avec le .json supplémentaire), mais même avec ce changement, je continue de recevoir des erreurs 404.
Je ne sais pas comment résoudre ce problème. Nous devons générer des liens d’invitation pour les envoyer via nos systèmes. Tout fonctionnait parfaitement jusqu’à aujourd’hui.
De plus, un PUT vers cette adresse renvoie BAD REQUEST, tandis qu’un PUT vers une adresse inexistante renvoie NOT FOUND. Je ne suis pas sûr que cela indique que le point de terminaison existe mais ne fonctionne pas correctement.
Peut-être devrais-je préciser que j’ai une instance de Discourse hébergée par vous à l’adresse https://d.strumenta.community/
Ce point de terminaison API a été déplacé vers https://{defaultHost}/invites.json car nous avons regroupé les invitations par e-mail et les invitations par lien.
Ok, alors je pense que la documentation n’est pas à jour
Cet endpoint génère-t-il un lien d’invitation sans envoyer d’e-mail ?
Car selon la documentation, la différence entre /invites.json et /invites/link.json réside dans l’envoi de l’e-mail.
De plus, une requête POST vers /invites.json me renvoie une erreur BAD REQUEST → ma faute, j’aurais dû utiliser " et non ’
Avec la correction, je reçois une réponse indiquant que l’utilisateur a été informé par e-mail, et j’aimerais éviter cela :
Il serait utile de recevoir une notification lors des modifications de l’API et d’avoir accès à la documentation actuelle, sinon des dysfonctionnements surviennent soudainement et il devient impossible de les corriger…
Je l’ajoute ici, simplement pour plus de visibilité :
$ curl 'http://localhost:3000/invites.json' -X 'POST' \
-H "Api-Key: d5fc02c5f4efaafacc82e4ff3410ae283d1c5da68ac43430d5133aaf4785593f" \
-H "Api-Username: dan" \
-H "Content-Type: application/json" \
-d "{\"max_redemptions_allowed\":5}"
{"id":18,"link":"http://localhost:3000/invites/6f524dba4ced35ecae709a8614db3b05","redemption_count":0,"max_redemptions_allowed":5,"custom_message":null,"updated_at":"2021-03-10T15:44:44.259Z","expires_at":"2021-04-09T15:44:44.258Z","expired":false,"topics":[],"groups":[]}%
Je mettrai à jour notre documentation API. Merci de m’avoir signalé cela et désolé pour le désagrément.
Ce serait bien que create renvoie le lien d’invitation existant au lieu de lever une erreur s’il provient du même utilisateur. La réponse d’erreur 422 est assez générique ; il m’a fallu un temps fou pour comprendre pourquoi mes tests échouaient.
Ajout d’une PR pour récupérer une invitation existante par adresse e-mail : FEATURE: Retrieve an existing link only invite by jessicah · Pull Request #12575 · discourse/discourse · GitHub
J’ai trouvé un drapeau non documenté skip_email qui empêche l’envoi de l’e-mail, vous permettant ainsi de récupérer simplement le lien. Transmettez-le dans le corps de la requête avec l’adresse e-mail et tout devrait fonctionner !
{
"email": "quelquun@test.com",
"skip_email": "true"
}
J’ai effectué quelques tests rapides et il est à noter que si vous l’utilisez pour générer un lien e-mail, vous ne pourrez plus revenir en arrière pour l’utiliser afin d’envoyer un e-mail automatiquement - emailed retourne toujours false une fois que skip_email a été utilisé.
Y a-t-il une raison pour que invites/retrieve ne soit pas dans la documentation sous Discourse API Docs ? Ou est-ce que je manque quelque chose.
Je veux inviter des adresses e-mail qui existent dans une base de données externe, seulement si a) elles n’ont pas déjà de compte, et b) si elles n’ont pas déjà été invitées (ce processus s’exécutera périodiquement et je ne veux pas spammer les personnes qui n’ont pas répondu assez vite à leur invitation). invites/retrieve.json semble être la bonne façon de vérifier b) d’après ce qui semble être dans le commit.
Il s’agit probablement d’un oubli de sa présence dans la documentation de l’API, je vais travailler à l’ajouter.
Ce serait bien si ceux-ci étaient générés par, ou du moins testés contre, le cœur actuel de Discourse.
Il semblerait qu’il y ait un moyen raisonnablement simple (ce qui signifie probablement 2 jours de travail et non l’heure que j’aimerais croire !) de faire exécuter des spécifications pour les tester. Oh, ou peut-être est-ce à cela que sert https://redocly.com/ ?
Ce qui serait vraiment agréable pour mon cas d’utilisation, c’est un moyen de récupérer toutes les invitations envoyées par tous les utilisateurs. Si « par tous les utilisateurs » est le point bloquant, il serait acceptable pour mon cas d’utilisation de récupérer toutes les invitations (quel que soit leur état).
Avec cette méthode, je suis obligé de sonder chaque possibilité, ce qui pourrait représenter 1000 adresses e-mail alors qu’il n’y en a probablement que quelques-unes dans la table.
How to get a password from database? - #3 by pfaffman indique que la base de données n’est pas exposée par défaut, donc utiliser du code pour accéder à la base de données à partir d’un processus externe n’est pas faisable directement, du moins pas avec mon implémentation actuelle – et ce ne serait peut-être pas une bonne idée d’exposer le port de la base de données de toute façon.
J’essaie d’automatiser les invitations et l’appartenance à des groupes pour les adresses e-mail dans une base de données externe.
Et deux fois, il a été fait référence au plugin data explorer (explorateur de données), ce qui est également la réponse ici, mais peut-être avez-vous besoin de savoir que vous pouvez Run Data Explorer queries with the Discourse API
ah oui, c’était le point clé qui me manquait – merci pour l’indication


