مرحباً، سؤال سريع: هل يمكن إرسال إشعارات للمستخدمين عبر واجهة برمجة التطبيقات (API)؟ (أو بطريقة أخرى).
في الوثائق، وجدت كيفية جلب إشعارات المستخدم وكيفية تعيينها كمقروءة، لكن لم أجد كيفية إرسال إشعارات جديدة (POST). إذا لم يكن ذلك ممكناً، أعتقد أنه يمكن دائماً استخدام الرسائل الخاصة كبديل.
أقدر أي توضيح بخصوص هذا الأمر. شكراً.
إعجابَين (2)
أعتقد أن ذلك سيتطلب إضافة. ما نوع الإشعار الذي تريده؟ هل يمكنك وصف حالة الاستخدام الخاصة بك؟
إعجابَين (2)
عادةً ما يتم استبدال إشعارات البريد الإلكتروني من خدمة خارجية بإشعارات Discourse. ستُقدَّم هذه الخدمة مجانًا للأعضاء (*). وهذا سيسمح بتوحيد كل شيء نحو Discourse، وتقديم حافز لتسجيل الدخول (بانتظام) إلى المنتدى. هذه هي الفكرة التي خطرت ببالي. لست متأكدًا مما إذا كان ذلك منطقيًا أم لا، أو ما إذا كانت هناك ثغرات في المنطق. أنا منفتح على أي اقتراح أو نقد.
[ (*): الأعضاء = مشاركون في المنتدى. على الأقل الأشخاص المسجلون في المنتدى. لا يزال يتعين تحديد ما إذا كان هناك حد أدنى للمشاركة أو مستوى ثقة مطلوب، أو ما إذا كان التسجيل كافياً.
هل سيستقبل الإضافة المعلومات ويطلق إشعارات في Discourse؟ هل يمكن تنفيذ الإشعارات (بسهولة أكبر) من خلال إضافة؟
إعجابَين (2)
يمكنني تخيل إضافة (plugin) تضيف مسارًا جديدًا، حيث يمكنك إرسال حمولة تحتوي على معرف المستخدم (أو عنوان البريد الإلكتروني)، ورابط، وعنوان لإنشاء إشعار. لا أعتقد أنه يمكن فعل ذلك دون إضافة، لكنني لم أفحص الكود عن كثب بعد.
بدأت بالأمس فقط في التفكير في إضافة إشعارات إلى إضافة أقوم بتطويرها، لذا فإني لست على دراية كافية بكيفية عملها.
3 إعجابات
أخطط لإضافة مماثلة بنفسي، مع التركيز على إشعارات موقعي غير البريدية حول Discourse، والتي يمكنك الاشتراك فيها عبر MessageBus وتكوين إشعارات دفع مركزية.
ما أخطط له هو مجرد وجود نقطة نهاية مخصصة لإنشاء إشعارات مخصصة، وبعد رؤية هذه الأجزاء أعتقد أن ذلك ممكن.
لإنشاء إشعار مخصص:
لتخصيص كيفية عرض عنصر الإشعار في قائمة الإشعارات:
https://github.com/discourse/discourse-code-review/blob/master/assets/javascripts/discourse/widgets/code-review-commit-approved-notification-item.js.es6
إذا كانت هناك واجهة برمجة تطبيقات أساسية لإنشاء الإشعار، فأعتقد أنه يمكن تنفيذ عنصر الإشعار هذا في مكون سمة، وهو ما سيكون أبسط حتى.
4 إعجابات
لا أعرف مدى تعقيد الأمر المحتمل، ولكن ألا يبدو من المنطقي إضافة إنشاء الإشعارات مباشرة إلى واجهة برمجة التطبيقات (API)؟ ربما يكون الفريق منفتحًا على ذلك، أو منفتحًا على طلب سحب (PR) (إذا كان هناك شخص قادر ومستعد للقيام بذلك)؟
إعجابَين (2)
لم يتم توثيق ذلك بعد، ولكن هناك نقطة نهاية واجهة برمجة تطبيقات لإنشاء إشعار:
POST /notifications(.:format) notifications#create {:format=>/(json|html|\*\/\*)/}
قد تتمكن من استخدام نوع الإشعار المخصص بدلاً من الاضطرار إلى إنشاء نوع خاص بك.
5 إعجابات
هذا رائع! شكرًا لك.
إذن، إذا فهمت الأمر بشكل صحيح، ففي حالة وجود نقطة نهاية (endpoint)، إذا كان هناك حاجة لتجاوز DefaultNotificationItem، فسيظل هناك حاجة إلى إضافة (plugin) فقط لتسجيل نوع الإشعار الإضافي المراد استخدامه في عنصر واجهة مستخدم مخصص؟
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 في غير ذلك؟
إعجابَين (2)
شكرًا لك، @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 وليس سلسلة نصية عشوائية… ما أريده هو القدرة على وضع رابط النموذج الذي استدعاه.
إعجابَين (2)
أظن أنك تقصد “لا يحدث شيء”؟
إذا أمكنك النقر عليه وإعادة التوجيه إلى عنوان URL انضممت إليه عبر واجهة برمجة التطبيقات، فسيكون ذلك مذهلاً حقًا.
إعجابَين (2)
ينشئ 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);
}
})
4 إعجابات
لا يعمل هذا معي…
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؟
لا يمكنني حقًا عكس هندسة هذا من الويب - أو هل يتم استدعاء هذه الواجهة البرمجية في مكان ما؟
إعجاب واحد (1)
تحتاج إلى ترميز قيمة data.
على سبيل المثال:
"data": "{\"topic_title\":\"Test\",\"original_post_id\":2222,\"original_post_type\":1,\"original_username\":\"User.Name\",\"revision_number\":1,\"display_username\":\"Text\"}"
4 إعجابات