@dax هل لا يزال الأمر كذلك في عام 2020، ألا يمكنك تحديد مشاركات في موضوع ما لمستخدمين ينتمون لمجموعة الناشر؟
نرغب في استخدام Discourse مع نظام التعلم الإلكتروني الخاص بنا… نرغب في وجود مجموعة واحدة من سبعة مواضيع تقريبًا تتحرك خلالها مجموعات مختلفة من المستخدمين (groups)، بحيث يمكنهم رؤية المشاركات ضمن مجموعتهم فقط. نفضل وجود مجموعة واحدة من المواضيع بدلاً من إنشاء نفس المواضيع مرارًا وتكرارًا مع كل مجموعة جديدة.
ربما ظهرت ميزة جديدة أخرى في غضون ذلك تجعل هذا ممكنًا؟ شكرًا على أي أفكار.
عذراً، سؤالك غير واضح ويبدو غير ذي صلة.
يمكنك إنشاء فئات، ويمكن تأمين الفئات باستخدام المجموعات.
ما يطلبه @HappyGezim هو ميزة “همس” مخصصة داخل موضوع معين، وهذا غير مدرج في خارطة طريقنا.
@sam شكرًا لك على ردك السريع! سأحاول توضيح سيناريونا الدقيق:
لدينا أربع فئات مُعدة، واحدة لكل دورة من الدورات الأربع التي نقدمها.
في كل فئة (دورة)، لدينا ما يقرب من 5 إلى 10 مواضيع، واحدة لكل “درس” في الدورة… بالإضافة إلى بضع مواضيع إضافية مثل “أسئلة تقنية” و"تعرّف على نفسك" وما إلى ذلك. مع وصول كل درس، يُطلب من الطلاب المساهمة في الموضوع ذي الصلة.
سنكون لدينا العديد من الدفعات من الطلاب يتقدمون عبر هذه الدورات، ونرغب في تقييد المنشورات في موضوع ما لـ “مجموعة” دفعتهم فقط. بهذه الطريقة، نحتفظ بالفئات والمواضيع نفسها ثابتة، ونقوم فقط بتعديل خصائص المستخدمين لتعيينهم لمجموعات مختلفة، والتي يمكننا إنشاؤها (?) عبر واجهة برمجة التطبيقات وتعيين الطلاب لها ديناميكيًا (?)
إذن هذا هو السياق الذي دفعني إلى التركيز على السؤال الرئيسي: “داخل موضوع محدد، هل يمكنني إنشاء رسالة تكون مرئية فقط للمستخدمين الذين ينتمون لمجموعة معينة؟”
دانيال، لدي أيضًا دورة أقوم بتشغيلها عبر Discourse. أستخدم فئة + فئة فرعية تسمح بأبسط طريقة للتقييد.
الفئة: دورة Acme
الفئة الفرعية: 2020-05 - محادثات الدورة
الطلاب في مجموعة محددة يرون فئة فرعية واحدة فقط.
ليس مثاليًا لكنه يعمل!
@waffleslop رائع. شكرًا لك. هل تنشئ هذه الفئات الفرعية يدويًا في كل مرة يكون لديك فيها مجموعة جديدة؟ (أو ربما عبر واجهة برمجة التطبيقات؟)
كنت أتمنى تجنب ذلك لأنه في كل مجموعة سأضطر إلى إعداد نفس الموضوعات الخمسة إلى العشرة الجديدة في فئة فرعية. قد يكون لدينا عدة مجموعات متزامنة تجري في أي دورة واحدة من الدورة أيضًا، مما يعني أنني سأحتاج إلى إبداء الإبداع في التسمية. لذا بناءً على مثالك…
2020-05-cohort-A محادثات الدورة
… أو ربما هناك طريقة لإنشاء فئات فرعية متداخلة لم ألقِ نظرة على ذلك بعد.
شكرًا مرة أخرى على أفكارك.
اجعل هذه الفئات للقراءة فقط.
عندما تحصل على مجموعة طلابية جديدة، أنشئ فئة جديدة لهذه المجموعة. اطلب من الطلاب النقر على أيقونة 
ثم اختيار “موضوع جديد” لإنشاء موضوع جديد لهذا الواجب ضمن فئة المجموعة. لقد طلبت منهم وضع وسم خاص بكل واجب لتسهيل تتبع ما إذا كان قد تم إنجاز الواجب ومتى (وقد أنشأت شارات تُمنح إذا قمت بـ “إعجاب” بموضوعهم، بل وحتى قمت بإنشاء نص برمجي للقيام بذلك لجميعهم، وإنشاء ملف CSV، ورفعه إلى نظام إدارة التعلم الجامعي الذي لم أرغب في استخدامه).
@pfaffman شكراً لك على مساهمتك.
كانت فكرتي العملية هي استخدام الفئات الفرعية لتجميع الأجيال (cohorts) تحت دورة معينة، لكنني رأيت هذا في واجهة المستخدم أثناء إنشاء فئة فرعية
هل فهمي صحيح بأن هذا يعني أنه لا توجد طريقة لاستخدام الفئات الفرعية لتجميع الأجيال تحت دورة ثم استخدام أذونات المجموعات للحد منها إلى تلك الفئة الفرعية؟ @waffleslop هل تمكنت من التقييد حسب الفئة الفرعية في نهجك؟ ربما أقرأ رسالة واجهة المستخدم بشكل خاطئ.
إذا لم تتمكن من تقييد فئة فرعية لمجموعة معينة، @pfaffman أعتقد أن نهجك (شكراً لشرحك) حيث تنشئ فئة جديدة لكل جيل هو الخيار الوحيد على الأرجح.
نظراً لأن مواضيعنا العشرة أو نحو ذلك في كل دورة ثابتة بشكل كبير، ولها تسمية وترقيم محددين، إلخ، فإنني أفكر في إنشاءها عبر واجهة برمجة التطبيقات (API) في كل مرة يتم فيها إنشاء جيل جديد في نظامنا. لذا، لكل جيل جديد ننشئه في نظام إدارة التعلم (LMS) الخاص بنا، سأستخدم واجهة برمجة التطبيقات للقيام بما يلي:
هل جربت هذا النهج بدلاً من الاعتماد على الطالب لإنشاء الموضوع بنفسه؟ أتساءل حول قيام طلاب مختلفين بإنشاء مواضيع بأسماء مختلفة قليلاً لنفس الواجب في الدورة.
غير واضح لي اقتراحك باستخدام “فئات للقراءة فقط” كجزء من حل هذه المشكلة.
شكراً جزيلاً لك على تخصيص الوقت لكتابة أفكارك!
إليك التنسيق:
الفئة: دورة أكمي
المجموعات: 2020-01_cohort, 2020-05_cohort
الفئات الفرعية:
أها، شكرًا لك @waffleslop. حسنًا، إذاً أنت تقول إنه يمكنك تقييد الفئة الفرعية إلى المجموعة وبالتالي منع الوصول إلى فئات فرعية أخرى. لقد أساءت فهم رسالة واجهة المستخدم التي نسختها أعلاه. 
لذلك، من المرجح أن تكون منهجيتنا هي استخدام واجهة برمجة التطبيقات (API) لـ:
أنا متأكد تقريبًا من أن الفئة الرئيسية يمكن أن تكون للقراءة فقط، بينما تكون الفئات الفرعية مقيدة بمجموعة واحدة فقط.
يمكنك ذلك، ولكن بهذه الطريقة تحتاج إلى إنشاء (والحفاظ عليها ما لم تنجح من المحاولة الأولى) فئات للقراءة فقط تحتوي على التعليمات مرة واحدة فقط، وعند إنشاء قسم، تحتاج إلى إنشاء فئة فرعية واحدة فقط.
أعتقد أن هذا هو السبب في أنني استخدمت الوسوم. سيقومون بوسم الموضوع بوسم الواجب، وبالتالي يمكن أن يكون الموضوع وصفيًا، ولن يضر أي شيء إذا اختاروا اسمًا غير مناسب.
لأي شخص يتبع النهج المذكور أعلاه — أي استخدام فئات فرعية لكل “دفعة” من الدورات وتكرار مواضيع النقاش في كل منها — تأكد من تمكين إعداد “السماح بأسماء مواضيع مكررة”، وإلا فلن يسمح لك Discourse بتكرار نفس المواضيع في كل فئة فرعية.
هذا جزء من سبب تفضيلي لحلي الذي يتمثل في وجود فئة واحدة للقراءة فقط تحتوي على المحتوى، مع قيام الطلاب بمناقشة هذا المحتوى عبر مواضيع جديدة في الفئة المخصصة لكل مجموعة تعليمية.
مرحباً @Daniel_McQuillen. كنت أتساءل عن سير دورتك التدريبية. أنا أفكر في تشغيل ثلاث دورات تدريبية، كل منها تضم عدة دفعات، وكنت مهتمًا بتجربتك حتى الآن.
أيضًا، هل تنوي إنهاء صلاحية أي من دوراتك أو الوصول إلى المناقشات؟
شكرًا مقدّمًا على مشاركتك، هانتر
مرحبًا هانتر،
نحن حاليًا في مرحلة الاختبار التجريبي، وتكامل Discourse يسير على ما يرام. نستخدم تكامل SSO لإجبار المستخدمين على تسجيل الدخول في موقعنا. لقد عمل هذا بشكل جيد، رغم أنني لاحظت ما يلي:
لا يقبل Discourse أسماء مستخدمين تحتوي على رمز “@”… فهو يقص اسم المستخدم ليحتوي فقط على الجزء الأول قبل “@”… وهذا قد يسبب مشاكل إذا قمت لاحقًا باستدعاء واجهات برمجة تطبيقات Discourse باستخدام ذلك الاسم كمُعامِل. لن يتعرف Discourse على اسم مستخدم مثل someone@example.com لأن اسم المستخدم المخزن في Discourse هو someone فقط… الحل السهل هو منع استخدام رمز “@” في أسماء المستخدمين الخاصة بك!
عندما يسجل شخص ما في موقعك، يجب عليك استدعاء واجهة برمجة تطبيقات Discourse صراحةً لمزامنة مستخدم SSO، حيث قد ترغب في القيام بأشياء مع هذا المستخدم (مثل إضافته إلى مجموعة Discourse) قبل زيارته لموقع Discourse لأول مرة (وهو ما سينشط المزامنة التلقائية لـ SSO). لدي موقع مبني على Django، لذا أستخدم مكتبة pydiscourse، وهناك طريقة sync_sso تجعل هذا الأمر سهلاً للغاية (pydiscourse · PyPI)
نعم، سنقوم بإنهاء صلاحية بعض الدورات التدريبية لدينا، وفي هذه الحالة سيقوم الخادم باستدعاء واجهة برمجة تطبيقات Discourse لإزالة المستخدم من المجموعة العامة لتلك الدورة، وكذلك من المجموعة المخصصة لدفعته ضمن هذه الدورة.
لقد أنشأت جداول في موقع Django الخاص بي تتتبع مجموعات “الدورات” هذه والمجموعات المختلفة لـ “الدفعات” داخل كل دورة. لذا أستخدم هذه المعلومات عند إضافة/إزالة الطلاب، وما إلى ذلك:
