Это связано с тем, что API https://{defaultHost}/invites/link.json перестал работать сегодня?
1 лайк
Не уверен — возможно? Я не знаком с этим endpoint.
Что ж, у нас сейчас несколько сотен писем от нашей автоматизации о том, что запросы не выполняются. Мы использовали конечную точку https://{defaultHost}/invites/link, но начали получать ошибку 404. Я проверил документацию, и там указано, что теперь нужно использовать https://{defaultHost}/invites/link.json (с дополнительным .json), но даже с этим изменением я продолжаю получать 404.
Я не уверен, как это исправить. Нам нужно генерировать ссылки для приглашений, чтобы отправлять их через наши системы. До сегодняшнего дня всё работало безупречно.
Кроме того, отправка PUT-запроса на этот адрес возвращает BAD REQUEST, а PUT-запрос на несуществующий адрес возвращает NOT FOUND. Не уверен, является ли это признаком того, что конечная точка существует, но просто не работает.
Возможно, мне стоит уточнить, что у меня есть экземпляр Discourse, размещённый вами по адресу https://d.strumenta.community/
Эта конечная точка API была перемещена в https://{defaultHost}/invites.json, так как мы объединили приглашения по электронной почте и по ссылкам.
2 лайка
Хорошо, тогда, думаю, документация устарела
Этот endpoint генерирует ссылку для приглашения, но не отправляет письмо?
Потому что, согласно документации, разница между /invites.json и /invites/link.json заключается в отправке письма
1 лайк
Кроме того, запрос к /invites.json возвращает BAD REQUEST — виноват, я должен использовать ", а не '**
После исправления я получаю ответ, что пользователю отправлено письмо, и я хотел бы это предотвратить:
Было бы полезно получать уведомления об изменениях в API и иметь доступ к актуальной документации, иначе всё может внезапно сломаться, и исправить это будет невозможно…
Добавляю это сюда для наглядности:
$ 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":[]}%
Я обновлю нашу документацию по API. Спасибо, что обратили на это внимание, и извините за неудобства.
7 лайков
Было бы здорово, если бы create возвращал существующую ссылку-приглашение вместо того, чтобы выбрасывать ошибку, когда приглашение уже создано тем же пользователем. Ответ с ошибкой 422 слишком общий, мне потребовалось много времени, чтобы понять, почему мои тесты не проходят.
1 лайк
Добавлен PR для получения существующего приглашения по адресу электронной почты: FEATURE: Retrieve an existing link only invite by jessicah · Pull Request #12575 · discourse/discourse · GitHub
1 лайк
Я обнаружил не задокументированный флаг skip_email, который предотвращает отправку письма, чтобы вы могли просто получить ссылку. Передайте его в теле запроса вместе с email, и всё должно работать!
{
"email": "someone@test.com",
"skip_email": "true"
}
Я провёл краткое тестирование, и стоит отметить: если вы используете этот флаг для генерации ссылки для письма, то вернуться и автоматически отправить письмо уже не получится — emailed всегда возвращает false, если был использован skip_email.
1 лайк
Есть ли какая-то причина, по которой invites/retrieve.json отсутствует в документации по адресу Discourse API Docs? Или я что-то упускаю.
Я хочу приглашать адреса электронной почты, которые существуют во внешней базе данных, только если: а) у них ещё нет аккаунта, и б) они ещё не были приглашены (этот процесс будет выполняться периодически, и я не хочу спамить людям, которые не успели ответить на своё приглашение достаточно быстро). Судя по тому, что видно в коммите, invites/retrieve.json — это правильный способ проверить пункт (б).
2 лайка
Скорее всего, это просто упущение, что его нет в документации к API. Я займусь тем, чтобы его добавили.
3 лайка
Было бы здорово, если бы они генерировались или хотя бы тестировались на актуальном ядре Discourse.
Кажется, есть довольно простой способ (который, вероятно, займёт 2 дня работы, а не 1 час, как мне бы хотелось верить!), чтобы запускать спецификации для их тестирования. О, или, может быть, именно для этого предназначен https://redocly.com/?
Для моего сценария было бы очень полезно иметь возможность получать все приглашения, отправленные всеми пользователями. Если ограничение «все пользователи» является критическим, для моих целей было бы достаточно получать все приглашения (независимо от их состояния).
С текущим методом я вынужден опрашивать каждую возможность, что может означать 1000 адресов электронной почты, хотя в таблице, скорее всего, их всего несколько.
В ссылке How to get a password from database? - #3 by pfaffman указывается, что база данных по умолчанию не доступна, поэтому использование кода для прямого доступа к БД из внешнего процесса в моей текущей реализации невозможно — и, возможно, в любом случае не стоит открывать порт базы данных.
Я пытаюсь автоматизировать процесс отправки приглашений и управления членством в группах для адресов электронной почты, хранящихся во внешней базе данных.
Дважды упоминался плагин Data Explorer, который также является ответом здесь, но, возможно, вам нужно знать, что вы можете использовать Run Data Explorer queries with the Discourse API
Ах да, это был тот самый ключевой момент, которого мне не хватало — спасибо за подсказку.
1 лайк