Is this related to the fact that the https://{defaultHost}/invites/link.json API stopped working today?
1 个赞
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.
2 个赞
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
1 个赞
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.
7 个赞
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 个赞
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 个赞
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 个赞
在 Discourse API Docs 下的文档中，是否有任何关于 invites/retrieve 的原因未被提及？或者是我错过了什么。
我想邀请外部数据库中存在的电子邮件地址，前提是 a) 他们还没有账户，并且 b) 他们还没有被邀请（此过程会定期运行，我不想对那些没有足够快回复邀请的人进行垃圾邮件轰炸）。根据提交中的内容来看，invites/retrieve.json 似乎是确定 b) 的正确方法。
2 个赞
这很可能只是 API 文档中遗漏的一个疏忽，我会努力将其添加上去。
3 个赞
如果这些（文档）是根据当前的 Discourse 核心生成的，或者至少是经过当前 Discourse 核心测试的，那就太好了。
看起来应该有一种相当简单的方法（这可能意味着需要两天的工作，而不是我希望相信的 1 小时！）来运行规范来测试它们。哦，或者也许这就是 https://redocly.com/ 的作用？
对我的用例来说，真正有帮助的是一种检索所有用户邀请的所有邀请的方法。如果“所有用户”是限制点，那么检索所有邀请（无论状态如何）对我的用例来说也可以接受。
使用此方法，我被迫轮询每一种可能性，这可能是 1000 个电子邮件地址，而表中可能只有少数几个。
How to get a password from database? - #3 by pfaffman 表明数据库默认情况下不暴露，因此使用代码从外部进程访问数据库是不可行的，至少在我目前的实现中是这样——而且无论如何暴露数据库端口可能也不是一个好主意。
我正试图在外部数据库中自动化电子邮件地址的邀请和组成员资格。
并且两次都提到了数据资源管理器插件（data explorer plugin），这在这里也是答案，但也许你需要知道你可以 Run Data Explorer queries with the Discourse API
啊，是的，这正是我遗漏的关键点——感谢您的指点
1 个赞