Привет, быстрый вопрос: можно ли отправлять уведомления пользователям через API (или другим способом)?
В документации я нашёл, как получать уведомления пользователя и как помечать их как прочитанные, но не нашёл, как отправлять (POST) новые. Если это невозможно, полагаю, всегда можно использовать личные сообщения.
Буду благодарен за любой комментарий по этому поводу. Спасибо.
Я думаю, для этого потребуется плагин. Какое уведомление вы хотите? Можете описать ваш сценарий использования?
Обычно это означает замену уведомлений по электронной почте от внешнего сервиса на уведомления Discourse. Сервис предоставлялся бы участникам бесплатно (*). Это позволило бы централизовать всё в Discourse и создать стимул для регулярного входа на форум. Именно такую идею я имел в виду. Не уверен, имеет ли это смысл или нет, и есть ли в рассуждениях пробелы. Готов к любым предложениям и критике.
[ (*): Участники = участники форума. По крайней мере, люди, зарегистрированные на форуме. Остаётся выяснить, требуется ли минимальный уровень участия или доверия, или достаточно просто регистрации. ]
Будет ли плагин получать информацию и запускать уведомления в Discourse? Уведомления можно (более легко) реализовать через плагин?
Я могу представить себе плагин, который добавляет маршрут, и вы можете отправить нагрузку с идентификатором пользователя (или адресом электронной почты), URL-адресом и заголовком, чтобы создать уведомление. Я не думаю, что это можно сделать без плагина, но я не изучал код достаточно внимательно.
Только вчера я начал задумываться о добавлении уведомлений в плагин, который я разрабатываю, поэтому я не очень хорошо знаком с тем, как это работает.
Я сам планирую создать похожий плагин, сделав центром не-электронных уведомлений для своего сайта Discourse. К ним можно будет подписаться через MessageBus и иметь единую конфигурацию push-уведомлений.
Мой план — просто создать пользовательскую конечную точку (endpoint) для создания пользовательских уведомлений. После просмотра этих фрагментов кода я считаю, что это выполнимо.
Для создания пользовательского уведомления:
Для настройки отображения элемента уведомления в списке уведомлений:
https://github.com/discourse/discourse-code-review/blob/master/assets/javascripts/discourse/widgets/code-review-commit-approved-notification-item.js.es6
Если бы существовал базовый API для создания уведомлений, я думаю, что этот виджет элемента уведомления можно было бы реализовать как компонент темы, что было бы ещё проще.
Я не знаю, насколько это может быть потенциально сложнее, но разве не логично добавить создание уведомлений прямо в API? Возможно, команда была бы открыта к этому или готова принять PR (если кто-то может и хочет это сделать)?
Это ещё не задокументировано, но существует конечная точка API для создания уведомлений:
POST /notifications(.:format) notifications#create {:format=>/(json|html|\*\/\*)/}
Возможно, вы сможете использовать тип уведомления custom, чтобы не создавать свой собственный.
Отлично! Спасибо.
Итак, если я правильно понимаю, для конечной точки, если возникает необходимость переопределить DefaultNotificationItem, всё равно потребуется плагин, чтобы зарегистрировать дополнительный тип уведомления для использования в пользовательском виджете?
Notification.types[:following] = 800
(из discourse-follow/plugin.rb at main · discourse/discourse-follow · GitHub)
При использовании типа custom он будет отображаться с помощью https://github.com/discourse/discourse/blob/master/app/assets/javascripts/discourse/app/widgets/custom-notification-item.js, поэтому для переопределения целевого url всё равно потребуется пользовательский виджет?
Я видел, как один плагин переопределяет «custom-notification-item» в похожей ситуации. Безопасно ли просто переопределять url, если в data есть что-то специфичное, а в остальных случаях возвращать this._super.url?
Спасибо, @renato!
Вот что у меня получилось.
Notification.create!(
notification_type: Notification.types[:custom],
user_id: 1,
topic_id: nil,
post_number: nil,
high_priority: true,
data: {
message: 'pfaffmanager.title',
display_username: 'pfaffman',
topic_title: 'my title'
}.to_json
)
Я вижу уведомление, но, как и следовало ожидать, (РЕДАКТИРОВАНО:) НИЧЕГО не происходит при клике. Также (это не было для меня очевидно, пока я не проверил), message — это I18n, а не произвольная строка. . . ). Мне бы хотелось иметь возможность указывать URL модели, которая вызвала это уведомление.
Я полагаю, вы имели в виду «ничего» не происходит?
Если бы вы могли нажать на него и перейти по URL, который вы присоединили через API, это было бы действительно потрясающе.
DefaultNotificationItem автоматически создаёт url, если вы заполните data.badge_id, topic_id или data.group_id.
Я протестировал этот подход, и он работает. Просто заполните data.url и используйте это в компоненте темы:
api.reopenWidget("custom-notification-item", {
url(data) {
return data.url || this._super(data);
}
})
У меня не получается это заставить работать…
POST https://XXX/notifications
Api-Key:XXX
Api-Username:system
Content-Type:application/json
Accept:application/json
{
"notification_type":9,
"user_id": 123,
"post_number": 1,
"topic_id": 956,
"data": {
"topic_title": "Test",
"original_post_id": 2222,
"original_post_type": 1,
"original_username": "User.Name",
"revision_number": 1,
"display_username": "Text"
}
}
В ответ я получаю:
{
"errors": [
"Data can't be blank"
],
"error_type": "record_invalid"
}
Ошибка форматирования, недопонимание? Или я что-то упускаю в поле data?
Я не могу это разобрать через веб-интерфейс — или этот API где-то вызывается?
Необходимо закодировать значение data.
Например:
"data": "{\"topic_title\":\"Test\",\"original_post_id\":2222,\"original_post_type\":1,\"original_username\":\"User.Name\",\"revision_number\":1,\"display_username\":\"Text\"}"