Is this related to the fact that the https://{defaultHost}/invites/link.json API stopped working today?
I’m not sure - it could be? I am not familiar with this endpoint.
Well, I have got a few hundreds emails from our automation now failing. We used the endpoint https://{defaultHost}/invites/link and we started getting 404. I check the documentation and the endpoint is now reported to be https://{defaultHost}/invites/link.json (with the extra .json), but also with that change I keep getting 404.
I am not sure how to fix that. We need to generate invite links to send them through our systems. It worked beautifully until today
Also, doing a PUT to that address return BAD REQUEST, but a PUT to an unexisting address returns NOT FOUND. I am not sure if this is an hint that the endpoint is there and it is just not working
Maybe I should specify that I have an instance of Discourse hosted by you at https://d.strumenta.community/
That API endpoint was moved to https://{defaultHost}/invites.json as we consolidated the email and link invites.
Ok, then I think the documentation is not up-to-date
Does this endpoint generates an invite link, but does not send an email?
Because according to the documentation the difference betweek /invites.json and and /invites/link.json is the sending of the email
Also, a post to /invites.json returns BAD REQUEST for me → my bad, I should use " and not '
With the correction, I get an answered telling the user was emailed, and I would like to prevent that:
It would be useful to have a notification when API changes and get access to the current documentation, otherwise stuff breaks all of a sudden and one cannot fix it…
Adding this here, just for visibility:
$ 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":[]}%
I will be updating our API documentation. Thank you for bringing that to my attention and sorry for the inconvenience.
It would be nice if create returned the existing invite link instead of throwing an error if it’s from the same user. The 422 error response is pretty generic, it took me ages to figure out why my tests were failing.
Added a PR for retrieving an existing invite by email address: https://github.com/discourse/discourse/pull/12575
I found an undocumented flag skip_email that prevents the email being sent so you can just grab the link. Pass it in the body with the email and you should be good!
{
"email": "someone@test.com",
"skip_email": "true"
}
I did some brief testing and it’s worth noting that if you use it to generate an email link, then you can’t go back and use it to send an email automatically - emailed always returns false once skip_email is used.
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.
Es ist wahrscheinlich nur ein Versehen, dass es in der API-Dokumentation fehlt. Ich werde daran arbeiten, es hinzufügen zu lassen.
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


