أعتقد أن هذه ميزة رائعة ولكن التنفيذ الحالي بسيط للغاية. تم بالفعل نشر معظم ميزات تصميم النماذج المفقودة بواسطة مستخدمين آخرين في هذا الموضوع لذا أود التركيز أكثر على خصوصية البيانات / الإدارة.
يرغب مجتمعي في استخدام نماذج الطلبات كنظام لإدارة المستخدمين في الغالب. لهذا الغرض، يجب أن تعمل النماذج بشكل مشابه لنظام الإبلاغ حيث يمكن للمسؤولين تحديد من يمكنه رؤية الطلبات ومن يمكنه الرد عليها. بخلاف ذلك، إذا استخدمنا قالب المنتدى الحالي، فإن المعلومات الشخصية للمستخدمين الجدد ستنتهي في فئة منتدى عامة وهو أمر غير مرغوب فيه. سيكون من الرائع أيضًا إذا كان يمكن ربط هذه النماذج بإدارة مجموعات المستخدمين، على سبيل المثال، إذا تقدم عضو جديد للانضمام إلى المجتمع ووافق المشرف على طلبه، فيجب أن يحصل تلقائيًا على مستوى الثقة x، والمجموعة y، ويفقد المجموعة z.
على سبيل المثال، هذه بعض الميزات التي ستكون مذهلة لتصبح جزءًا أصيلًا من Discourse: بوت Discord Appy. حاليًا، نستخدم بوت Discord Appy ولكنه يسبب عبئًا إضافيًا على المسؤولين والمشرفين للحفاظ على كل شيء متزامنًا.
بالنسبة لي، هذا ليس حلاً كافياً. هذا يعني أن جميع المجندين الجدد سيرون تطبيقات المجندين الآخرين، مما يجعل معلوماتهم الخاصة (البريد الإلكتروني، العمر، إلخ) أكثر وضوحًا مما ينبغي.
لهذا السبب سأطلب أن يعمل نموذج الطلب بشكل أقرب إلى كيفية عمل نظام الإبلاغ. حيث يمكن للمستخدمين الجدد إنشاء مدخلات ولكن يمكن للموظفين فقط (المسؤولين، المشرفين، مجموعات المستخدمين المحددة) الوصول فعليًا إلى تلك المدخلات.
تحرير: إحدى الطرق التي يمكن أن يعمل بها هذا إذا كان هناك إعداد فئة يجعل من الممكن لمؤلفي الموضوعات رؤية موضوعاتهم الخاصة فقط.
يبدو أن المراسلة الجماعية قد تكون أكثر ملاءمة لك، أي يتم تقديم الطلبات عن طريق إرسال رسالة إلى مجموعة بدلاً من إنشاء موضوع في فئة ولا يمكن رؤية الرسائل إلا لأعضاء تلك المجموعة (بالإضافة إلى المرسل).
للأسف، قوالب النماذج غير متاحة للمراسلة الجماعية. أعتقد أنني سألت عن هذا في سياق استفسارات الدعم، فعل شخص ما ذلك، لكنني لا أعرف ما إذا كان هذا شيئًا مخططًا له في المستقبل.
كما أنها أكثر مرونة مع المراسلة الجماعية لأن المشاركين يمكن إضافتهم/إزالتهم حسب الاقتضاء. على سبيل المثال، إذا كنت تقوم بالتجنيد لوظيفة تقنية، فقد تذهب الطلبات إلى مجموعة الموارد البشرية وبمجرد قيامهم بفحوصات السلامة على الطلب، يمكنهم إضافة المجموعة التقنية ذات الصلة كمشارك.
أود بالتأكيد أن أرى قوالب النماذج ممتدة إلى المراسلة الجماعية في نهاية المطاف لسيناريوهات كهذه.
للأسف، هذا لن يغطي احتياجاتنا بالكامل لأننا نحتاج إلى ميزات نموذج التطبيق الكلاسيكي:
قوائم منسدلة
إجابات الاختيار من متعدد
أدوات التنسيق
حقول شرطية (إذا كانت الإجابة على السؤال أ هي ب، فاعرض الحقل ج)
القدرة على مراجعة الطلبات من قبل المشرفين/المسؤولين
تخزين طويل الأجل للطلبات لمجموعة متغيرة من المشرفين/المسؤولين (لهذا السبب لن تعمل المراسلة الجماعية معنا أيضًا، حيث ينضم الأشخاص ويغادرون فريق العمل بمرور الوقت)
خصوصية بيانات كافية - أي يجب أن يتمكن المستخدمون فقط من رؤية طلبهم الخاص
إدارة مستخدم آلية (إذا تم قبول الطلب أ، فامنح المستخدم المجموعة ب و/أو قم بإزالة المستخدم المجموعة ج).
أعتقد أن الحل المؤقت سيكون تقديم إعداد فئة جديد يمكن للمسؤولين تحديده يسمى “يمكن للمستخدمين فقط رؤية مواضيعهم الخاصة”. سيغطي هذا معظم النقاط التي أثيرت أعلاه حيث يمكن استخدام قالب النموذج التجريبي دون جعله مرئيًا لكل مستخدم في مجموعة مستخدم معينة. ثم ربما بمرور الوقت يمكن إضافة الوظائف المتبقية التي ذكرها الملصقون الآخرون وأنا إلى النموذج من قبل المطورين.
لقد جربت Custom Wizard من قبل ولكنه كسر بطريقة ما بعض حقول إعدادات discourse الافتراضية في قسم المسؤول. بعد ذلك، قمت بتعطيل المكون الإضافي وعملت حقول إعدادات discourse بشكل طبيعي مرة أخرى، ربما لم يكن المكون الإضافي متوافقًا مع أحدث إصدار من discourse في ذلك الوقت.
شكرا لك! لم أكن على علم بهذا المكون الإضافي لجهة خارجية (حتى الآن اقتصرت على المكونات الإضافية الرسمية فقط بعد أن واجهت بعض المشكلات مع Custom Wizard).
