هل يُخطط لإضافة قالب Community Workflow؟ أعتقد أنه يمكن أن يضيف قيمة كبيرة إلى هذا التنفيذ الرائع.
لا أعرف القيود التقنية، لكنني أعتقد أن Discourse Discovery يمكنه تمكين/تعطيل هذه الوظيفة وإعادة استخدام الاتصال بنظام Discourse البيئي.
حسنًا، لم أكن أراه على الأرجح لأنني بحاجة إلى التحديث، شكرًا لك.
[تعديل] كل شيء على ما يرام بعد التحديث، شكرًا جزيلاً لك على هذا التحديث اليدوي 
إعجاب واحد (1)
مرحباً @j.jaffeux ، عند استخدام المحفّز “مستخدم جديد”، أودّ أن يحدث الإجراء التالي فقط إذا تم تفعيل حساب ذلك المستخدم الجديد (لإستبعاد البوتات التي تسجّل مستخدمين جدد). هل يجب عليّ استخدام حالة “معتمد” كفلتر لهذا الغرض؟ شكراً.
وإذا كان افتراضي أعلاه صحيحاً، فكيف أحدد القيمة TRUE؟ هل أكتب “True” أم “T”؟ شكراً؟
يبدو أنه نجح أخيرًا! يسعدني كثيرًا وجود هذه الميزة
3 إعجابات
بدلاً من سحب وإفلات user.approved، ابقَ في الوضع العادي وحدد user.approved في القائمة، وسترى ما يلي:
هل من الممكن أن يكون
الحدث المُشغِّل: ردّ مستخدم مُعَدّ (staged) في فئة محددة
الإجراء: يُغلق موضوع الرد تلقائيًا - على غرار
لا، نحتاج إلى بعض التفاصيل المفقودة لهذا الأمر.
شكرًا - هل تقصد أن هناك بعض التفاصيل أو نقاط البيانات لا تزال مفقودة من Workflows لدعم هذه الحالة الاستخدام؟
إعجاب واحد (1)
شكراً، لقد قمت بذلك، لكن يبدو أن مرشح user.approved لا يقوم بتصفية المستخدمين الذين سجّلوا حساباتهم وأكّدوها.
حاولتُ منذ ساعات بدء العمل باستخدام سير العمل (Workflows)، لكنني لم أستطع جعل الذكاء الاصطناعي يعمل دون ظهور خطأ. ربما سأغيّر نموذج الذكاء الاصطناعي ثم أحاول مرة أخرى.
ما أحاول تحقيقه هو شيء من هذا القبيل: (وهو موضوع ذو صلة وثيقة بالمناقشة الأخيرة!)
- يعمل مجدول المهام (Scheduler) مرة واحدة يوميًا.
- ابحث عن المنشورات التي لم تتلقَّ أي ردود منذ 30 إلى 365 يومًا. (باستخدام مستكشف البيانات)
- لخص الموضوعات إذا لم تكن ملخصة بعد + احفظها في جدول البيانات.
- قدّم الملخص وآخر منشور إلى الذكاء الاصطناعي، واسأله عما إذا كان هناك مشكلة غير محلولة أو شيء يحتاج إلى متابعة.
- احفظ رأي الذكاء الاصطناعي، سواء كان بحاجة إلى منشور متابعة أم لا. (في جدول البيانات)
- اختر من المنشورات التي عالجها الذكاء الاصطناعي واحدًا للرد عليه.
- ردّ عليه عبر بوت يسأل عن متابعة أو تحديث، أو يسأل عما إذا كان قد تم حل المشكلة.
باختصار، أحاول فقط إنشاء سير عمل يحاول تحقيق بعض التفاعل العشوائي مع المنشورات التي أصبحت قديمة، لكنها قد تحتاج إلى منشور متابعة.
هل لدى أي شخص أي أفكار؟ كان بإمكاني الحصول على المنشورات باستخدام مستكشف البيانات والحصول على ملخص من الذكاء الاصطناعي. لكنني لم أتمكن من جعل جداول البيانات تعمل، ولم أتمكن من الوصول إلى مرحلة النشر التلقائي. لكنني اقتربت إلى حد ما.
فكرتي كانت تقسيم ذلك إلى عدة سير عمل:
- سير عمل واحد يجلب المنشورات الأقدم ويكتب الملخص. (يُحفظ في جدول البيانات)
- سير عمل آخر يراجع الملخص وآخر منشور لمعرفة ما إذا كان يجب نشر متابعة. (يُحفظ في جدول البيانات)
- سير عمل ثالث ينظر إلى جدول البيانات ويختار المنشور الذي يجب أن يتلقى ردًا، ويحدد نوع الرد الذي يجب الحصول عليه، ثم ينشر الرد عبر حساب بوت.
لست متأكدًا مما إذا كنت قد فهمت كيفية استخدامه، لكن هذه الإضافة لديها الكثير من الإمكانات!
إعجاب واحد (1)
إنه موجود في المخرجات، حيث يمكنك تحديد بيانات JSON بنفسك.
إعجاب واحد (1)
@j.jaffeux متابعةً لسؤال أعلاه، قمت بفتح طلب سحب (PR) يضيف إجراء «حدث» إلى سير العمل:
يضيف هذا الطلب:
- حدث → إغلاق الحدث
- حدث → فتح الحدث
يستقبل الإجراء معرّف الموضوع (topic ID)، ويستخرج الحدث من منشور الموضوع الأول، ثم يحدّث الحدث عبر مسار مزامنة تعديل المنشور/الحدث المعتاد.
قمت باختبار الاتجاه الأصلي لاستخدام الحالة مع:
إنشاء منشور → حدث / إغلاق الحدث
باستخدام Input → topic.id.
عند الرد على موضوع الحدث، يُغلق الحدث بينما يبقى الموضوع نفسه مفتوحًا، ويظهر التغيير مباشرةً في واجهة المستخدم.
يتضمن طلب السحب تغطية لاختبارات الوحدة/التكامل، وقد نجح اختبار discourse-events الكامل مع 1124 مثالًا / 0 إخفاقات.
يُعالج هذا الجانب المتعلق بإجراء الحدث من حالة الاستخدام التي أشرتُ إليها أعلاه. يمكن بعد ذلك معالجة شروط المستخدم/الفئة/أصل البريد الإلكتروني بشكل منفصل من خلال محفّز/شروط سير العمل.
إعجابَين (2)
هل لديكم أي نصائح حول وضع وسوم تلقائية (auto-tagging) للردود القادمة من وكيل الذكاء الاصطناعي (AI agent)؟ جربت سير العمل التالي، لكنه لا يلتقط الردود من مستخدم الوكيل.
مجرد معلومة، هذا الوسم مخفي، لكن الوكيل موجود في مجموعة تملك صلاحية رؤيته.
{
"id": "6",
"name": "My workflow",
"nodes": [
{
"id": "a8490306-e7e7-42e4-b909-851f3c4fbcba",
"type": "trigger:topic_created",
"typeVersion": "1.0",
"name": "When a new personal message is created",
"parameters": {
"topic_type": "personal_messages"
},
"credentials": {},
"webhookId": null,
"position": {
"x": 178.6210678807947,
"y": -18.94519916824343
}
},
{
"id": "a80813a3-35cf-414e-98b8-9892f3eab496",
"type": "condition:filter",
"typeVersion": "1.0",
"name": "Keep PMs from Navigator",
"parameters": {
"combinator": "and",
"conditions": [
{
"id": "sender_is_navigator",
"operator": {
"type": "string",
"operation": "equals",
"singleValue": false
},
"leftValue": "={{ $json.post.username }}",
"rightValue": "Navigator"
}
]
},
"credentials": {},
"webhookId": null,
"position": {
"x": 290.515625,
"y": -18.281249999999993
},
"notes": "",
"notesInFlow": false,
"alwaysOutputData": false
},
{
"id": "acfcf305-1a04-4d2e-876c-48b015dc038c",
"type": "action:topic_tags",
"typeVersion": "1.0",
"name": "Add onboarding-initiated tag",
"parameters": {
"topic_id": "={{ $json.topic.id }}",
"operation": "add",
"tag_names": "onboarding-initiated",
"actor_username": "Navigator"
},
"credentials": {},
"webhookId": null,
"position": {
"x": 513.1770833333333,
"y": -27.32031249999998
},
"notes": "",
"notesInFlow": false,
"alwaysOutputData": false
}
],
"connections": {
"Keep PMs from Navigator": {
"main": [
[
{
"node": "Add onboarding-initiated tag",
"type": "main",
"index": 0
}
]
]
},
"When a new personal message is created": {
"main": [
[
{
"node": "Keep PMs from Navigator",
"type": "main",
"index": 0
}
]
]
}
},
"settings": {},
"staticData": {},
"pinData": {},
"versionId": "6271bac1-9349-4594-8bc5-2b1aeb154fcc",
"activeVersionId": "6271bac1-9349-4594-8bc5-2b1aeb154fcc",
"versionCounter": 31
}
إعجاب واحد (1)
أودّ كثيراً أن يكون هناك إجراء تلقائي عند إنشاء حدث، يتم بموجبه تسجيل المُنشئ تلقائياً في الحدث بشكل افتراضي. هذا سيتيح لنا التعامل مع جميع الحالات، خاصةً في حالتي أنا! 
إعجابَين (2)
لدينا عقدة لحدث يُقام الأسبوع المقبل
4 إعجابات
نعم، أعتقد أن هذا يمكن أن ينسجم بشكل طبيعي مع منطقة الفعاليات (Event) نفسها ضمن سير العمل (Workflows).
في طلب الإرسال (PR) الحالي لديّ، FEATURE: Add event actions to workflows - Pull Request #42932 - discourse/discourse - GitHub ، لقد أضفت قسم فعاليات (Event) في منشئ سير العمل. في الصورة الملتقطة في وصف طلب الإرسال، فإن فتح قائمة الفعاليات (Event) يوفر حاليًا عمليتين:
- إغلاق الفعالية (Close event)
- فتح الفعالية (Open event)
هاتان هما العمليتان الوحيدتان المتعمدات في طلب الإرسال هذا لأنهما ضمن نطاق التغيير الذي أحاول الحصول على مراجعة له.
قد يؤدي استخدامك إلى إضافة عملية أخرى إلى نفس قائمة الفعاليات، على غرار تحديد الحضور (Set attendance) / إضافة مشارك (Add attendee). يمكن لسير العمل بعد ذلك استخدام كاتب الفعالية كمستخدم وإعداد حضوره إلى حاضر (Going) عند إنشاء الفعالية.
أعتقد أن من الأفضل تنفيذه بشكل عام - من خلال اختيار المستخدم وحالة الحضور - بدلاً من وجود إجراء خاص بحالة محددة فقط لـ “تسجيل الكاتب تلقائيًا”.
سأقوم بالنظر في هذا كمتابعة، على الأرجح كطلب إرسال منفصل حتى يبقى طلب الإرسال الحالي لفتح/إغلاق الفعاليات مركزًا على هدفه.
إعجاب واحد (1)
لم أكن قد رأيت ردّك قبل أن أنشر ردّي أعلاه.
بما أنك ذكرت أنّ عقدة Event ستصل الأسبوع المقبل، فسأختبر أيضًا PR الحالي محليًا مقابل فروع PR المفتوحة الأخرى في discourse-events / Workflows التي تلمس نفس المجال، بدلاً من الاعتماد فقط على CI مقابل main.
إذا وجدت أي تداخل أو تعارض حقيقي، فسأبلّغ عنه في PR على GitHub المعنيّ بدلاً من إرباك هذا الموضوع.
إعجاب واحد (1)
أعتقد أن السبب في ذلك هو أن هذا المستخدم يجب أن يكون ضمن pm_tags_allowed_for_groups، ويمكن القول إن رسالة الخطأ كان من الممكن أن تكون أوضح… سأقوم بتحسينها.
تعديل: سيتم تحسينها عبر FIX: provides a better error when user can't tag PM - Pull Request #43019 - discourse/discourse - GitHub
5 إعجابات