招待リンクを作成するためのAPIエンドポイントが/invites.jsonに移動しました

特徴
1

Is this related to the fact that the https://{defaultHost}/invites/link.json API stopped working today?

「いいね！」 1
Improve invite system
2

I’m not sure - it could be? I am not familiar with this endpoint.

3

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

4

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

5

Maybe I should specify that I have an instance of Discourse hosted by you at https://d.strumenta.community/

6

That API endpoint was moved to https://{defaultHost}/invites.json as we consolidated the email and link invites.

「いいね！」 2
7

Ok, then I think the documentation is not up-to-date

Screenshot 2021-03-10 at 16.36.16
Screenshot 2021-03-10 at 16.36.161926×555 101 KB

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

「いいね！」 1
8

Also, a post to /invites.json returns BAD REQUEST for me → my bad, I should use " and not '

Screenshot 2021-03-10 at 16.39.47
Screenshot 2021-03-10 at 16.39.473334×1066 175 KB

With the correction, I get an answered telling the user was emailed, and I would like to prevent that:

Screenshot 2021-03-10 at 16.44.21
Screenshot 2021-03-10 at 16.44.211090×446 33.9 KB

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…

9

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.

「いいね！」 7
14

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.

「いいね！」 1
15

Added a PR for retrieving an existing invite by email address: FEATURE: Retrieve an existing link only invite by jessicah · Pull Request #12575 · discourse/discourse · GitHub

「いいね！」 1
16

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.

「いいね！」 1
17

Discourse API Docs に、招待/取得に関する記述がないのは何か理由があるのでしょうか？それとも私が見落としているのでしょうか。

外部データベースに存在するメールアドレスを招待したいのですが、a) すでにアカウントを持っていない場合、かつ b) すでに招待されていない場合のみ招待したいと考えています（このプロセスは定期的に実行され、招待にすぐに応答しなかった人をスパムしたくありません）。invites/retrieve.json は、コミットの内容から判断すると、b) を確認するための適切な方法のようです。

「いいね！」 2
18

APIドキュメントに記載がないのは、単なる見落としだと思われます。追加作業を進めます。

「いいね！」 3
20

それらが現在のDiscourseコアによって生成されるか、少なくともテストされるといいですね。

仕様を実行してテストするための、それほど難しくない方法（おそらく私が信じたい1時間ではなく2日間の作業になるでしょう！）があるはずです。ああ、あるいは、https://redocly.com/ はそのためにあるのでしょうか？

21

私のユースケースにとって本当にありがたいのは、すべてのユーザーによって招待されたすべての招待を取得する方法です。もし「すべてのユーザーによって」が実現不可能な点であれば、私のユースケースでは（状態に関係なく）すべての招待を取得できれば問題ありません。

この方法では、テーブルに存在する可能性が低い1000件のメールアドレスであっても、すべての可能性をポーリングすることを強いられます。

How to get a password from database? - #3 by pfaffman は、データベースはデフォルトでは公開されていないことを示しているため、外部プロセスからコードを使用してDBにアクセスすることは、少なくとも私の現在の実装では直接はできません。また、いずれにしてもDBポートを公開するのは良い考えではないかもしれません。

外部データベースにあるメールアドレスの招待とグループメンバーシップを自動化しようとしています。

22

そして2回、データエクスプローラープラグインに言及がありましたが、これもここでの答えです。ただし、Run Data Explorer queries with the Discourse API でできることも知っておく必要があるかもしれません。

23

ああ、なるほど、それが私が欠けていた重要な点でした。教えてくれてありがとうございます。

「いいね！」 1