Hängt das damit zusammen, dass die API https://{defaultHost}/invites/link.json heute nicht mehr funktioniert?
1 „Gefällt mir“
Ich bin mir nicht sicher – es könnte sein? Ich bin mit diesem Endpunkt nicht vertraut.
Nun, ich habe einige hundert E-Mails von unserer Automatisierung erhalten, die jetzt fehlschlagen. Wir haben den Endpunkt https://{defaultHost}/invites/link verwendet und erhielten plötzlich 404-Fehler. Ich habe die Dokumentation geprüft, und dort wird der Endpunkt nun als https://{defaultHost}/invites/link.json (mit der zusätzlichen .json-Erweiterung) angegeben. Doch selbst mit dieser Änderung erhalte ich weiterhin 404-Fehler.
Ich bin mir nicht sicher, wie ich das beheben soll. Wir müssen Einladungslinks generieren, um sie über unsere Systeme zu versenden. Bis heute hat das einwandfrei funktioniert.
Außerdem führt ein PUT an diese Adresse zu einem BAD REQUEST, während ein PUT an eine nicht existierende Adresse NOT FOUND zurückgibt. Ich bin mir nicht sicher, ob dies ein Hinweis darauf ist, dass der Endpunkt vorhanden ist, aber einfach nicht funktioniert.
Vielleicht sollte ich erwähnen, dass ich eine von Ihnen gehostete Discourse-Instanz unter https://d.strumenta.community/ habe.
Dieser API-Endpunkt wurde zu https://{defaultHost}/invites.json verschoben, da wir die E-Mail-Einladungen und Link-Einladungen zusammengelegt haben.
2 „Gefällt mir“
Ok, dann scheint die Dokumentation nicht auf dem neuesten Stand zu sein.
Generiert dieser Endpunkt einen Einladungslink, sendet aber keine E-Mail?
Laut der Dokumentation liegt der Unterschied zwischen /invites.json und /invites/link.json nämlich im Versenden der E-Mail.
1 „Gefällt mir“
Außerdem liefert ein POST an /invites.json für mich einen BAD REQUEST zurück → mein Fehler, ich sollte " und nicht ’ verwenden**
Mit der Korrektur erhalte ich eine Antwort, dass dem Benutzer eine E-Mail gesendet wurde, und ich möchte das verhindern:
Es wäre hilfreich, bei API-Änderungen eine Benachrichtigung zu erhalten und Zugriff auf die aktuelle Dokumentation zu haben, sonst gehen Dinge plötzlich kaputt und man kann sie nicht beheben…
Ich füge dies hier nur zur besseren Sichtbarkeit hinzu:
$ 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":[]}%
Ich werde unsere API-Dokumentation aktualisieren. Vielen Dank, dass Sie mich darauf aufmerksam gemacht haben, und entschuldigen Sie bitte die Unannehmlichkeiten.
7 „Gefällt mir“
Es wäre schön, wenn create den bestehenden Einladungslink zurückgeben würde, anstatt einen Fehler auszulösen, wenn er vom selben Benutzer stammt. Die 422-Fehlerantwort ist ziemlich allgemein gehalten; es hat ewig gedauert, bis ich herausgefunden habe, warum meine Tests fehlschlugen.
1 „Gefällt mir“
Ein PR zum Abrufen einer bestehenden Einladung per E-Mail-Adresse wurde erstellt: FEATURE: Retrieve an existing link only invite by jessicah · Pull Request #12575 · discourse/discourse · GitHub
1 „Gefällt mir“
Ich habe einen nicht dokumentierten Flag skip_email gefunden, der verhindert, dass die E-Mail gesendet wird, sodass Sie einfach den Link abrufen können. Geben Sie ihn im Body zusammen mit der E-Mail-Adresse an, und es sollte funktionieren!
{
"email": "someone@test.com",
"skip_email": "true"
}
Ich habe kurze Tests durchgeführt. Beachten Sie bitte: Wenn Sie den Flag verwenden, um einen E-Mail-Link zu generieren, können Sie diesen Link später nicht mehr verwenden, um eine E-Mail automatisch zu versenden – emailed gibt nach der Verwendung von skip_email immer false zurück.
1 „Gefällt mir“
Gibt es einen Grund, warum invites/retrieve nicht in der Dokumentation unter Discourse API Docs aufgeführt ist? Oder übersehe ich etwas.
Ich möchte E-Mail-Adressen einladen, die in einer externen Datenbank vorhanden sind, nur wenn a) sie noch kein Konto haben und b) sie nicht bereits eingeladen wurden (dieser Prozess wird periodisch ausgeführt und ich möchte Leute nicht spammen, die nicht schnell genug auf ihre Einladung geantwortet haben). invites/retrieve.json scheint der richtige Weg zu sein, um b) herauszufinden, basierend darauf, was im Commit zu sehen ist.
2 „Gefällt mir“
Es ist wahrscheinlich nur ein Versehen, dass es in der API-Dokumentation fehlt. Ich werde daran arbeiten, es hinzufügen zu lassen.
3 „Gefällt mir“
Es wäre schön, wenn diese durch den aktuellen Discourse-Kern generiert oder zumindest gegen ihn getestet würden.
Es müsste doch einen einigermaßen einfachen Weg geben (was wahrscheinlich 2 Tage Arbeit bedeutet und nicht die 1 Stunde, die ich gerne glauben würde!), um Spezifikationen auszuführen, um sie zu testen. Oh, oder vielleicht ist das das, was https://redocly.com/ tun soll?
Was für meinen Anwendungsfall wirklich schön wäre, wäre eine Möglichkeit, alle von allen Benutzern eingeladenen Einladungen abzurufen. Wenn „von allen Benutzern“ der Knackpunkt ist, wäre es für meinen Anwendungsfall in Ordnung, alle Einladungen abzurufen (unabhängig vom Status).
Mit dieser Methode bin ich gezwungen, jede Möglichkeit abzufragen, was 1000 E-Mail-Adressen sein könnten, obwohl sich wahrscheinlich nur wenige in der Tabelle befinden.
How to get a password from database? - #3 by pfaffman deutet darauf hin, dass die Datenbank standardmäßig nicht offengelegt wird. Daher ist der Zugriff auf die Datenbank über Code aus einem externen Prozess zumindest mit meiner aktuellen Implementierung nicht direkt möglich – und es wäre wahrscheinlich ohnehin keine gute Idee, den Datenbank-Port offenzulegen.
Ich versuche, Einladungen und Gruppenmitgliedschaften für E-Mail-Adressen in einer externen Datenbank zu automatisieren.
Und zweimal wurde auf das Data Explorer Plugin verwiesen, was auch hier die Antwort ist, aber vielleicht müssen Sie wissen, dass Sie Run Data Explorer queries with the Discourse API können
ah ja, das war der entscheidende Punkt, den ich verpasst habe – danke für den Hinweis
1 „Gefällt mir“