شكراً @denvergeeks، ولكن هذا ليس ضمن خطة اشتراك مدفوعة - كل شيء يأتي من جيبي الخاص (باستثناء عندما يتم تعويضه بمساهمات صغيرة عرضية من الأعضاء).
إذًا أنت تستضيف بنفسك؟
شكراً @Nathank
نعم، لقد قمت الآن بتثبيت إضافة Custom Wizard، على الرغم من عدم نجاحي حتى الآن في جعلها تفعل ما أريده.
الوظائف التي تبدو الأكثر انطباقًا تم تمييزها على أنها للمشتركين فقط، لا يمكنني استبعاد الأساليب البديلة - ولكن حتى الآن لا توجد حلول أنيقة تتعامل مع التعقيد المتضمن في تحديد الأشخاص الذين لديهم الخصائص المؤهلة لعضو منتدى خاص (كما تم إنشاؤها عبر حقل مخصص منسدل / متعدد الاختيارات) مع تصفية جميع الآخرين كمتقدمين للمنتدى العام.
ربما لا أحاول حتى - ربما أقوم فقط بتعيين عضوية المجموعة يدويًا وفقًا لاستجابات المتقدمين المستلمة، عند الموافقة على التسجيلات. (تجربة تسجيل قبيحة للعامة على الرغم من ذلك)
هناك أيضًا
نعم، أنت على حق. ستحتاج إلى اشتراك مجتمعي مجاني لاستخدام هذه الميزات (خاصة إضافة إلى مجموعة)، مما يزيد من العناء قليلاً. ولكن لا يزال بالإمكان القيام بذلك.
شكراً @nathank.
لقد قدمت طلبًا للاشتراك المجتمعي المجاني - سنرى كيف يسير الأمر.
يجب أن أعترف بأنني متوتر بعض الشيء بشأن الاعتماد الدائم على مكون إضافي يمكن أن يغير سياسته “المجانية” في أي وقت. هل هناك مخرج إذا حدث ذلك؟
نوعًا ما؛ إذا انتهت صلاحية الاشتراك لأي سبب، فسيظل المعالج يعمل؛ فقط التغييرات على ميزة هذا المشترك ستكون مقفلة.
بالنظر إلى هذا الموضوع، من الغريب أنك لم تتمكن من جعل الأتمتة تعمل. يبدو هذا خطأً فادحًا - ويمكنني تكراره.
مع حالة الاستخدام الخاصة بك، قد يكون من الأفضل الدعوة إلى إصلاح ذلك، والنظر إلى المكون الإضافي للمعالج المخصص كحل بديل.
إعجابَين (2)
حالة الاستخدام الخاصة بي متشابهة أيضًا. أنا أقوم بإنشاء مجتمع خاص (مدفوع في حالتي)، ولكني أريد السماح للزوار بإنشاء حساب ورؤية محتوى محدود (دعائي) دون الدفع. (لا يوجد وصول مجهول، لذلك قمت بتعيين login required.)
عندما تنتهي من كل شيء، @Paul_King هل تمانع في تلخيص الإضافات التي تستخدمها في النهاية، والإعداد الذي تستخدمه بما في ذلك الأتمتة والتحقق (إلخ)، وأي مشاكل؟ شكراً مقدماً.
@nathank هل أفهم بشكل صحيح أنه إذا كان لدي مجموعة زوار ومجموعة أعضاء (مدفوعة)، يمكنني ببساطة تقييد الوصول إلى الفئات عن طريق تغيير إعداد الأمان “الجميع”؟ (مع الحرص على التحقق من جميع الفئات الفرعية أيضًا، لأن إعدادات الأمان لا تُورث؟ – شيء تعلمته بالأمس، لم يكن بديهيًا وخطيرًا محتملًا! Subcategory does not inherit security settings) على وجه الخصوص، لن ترتفع مستويات الثقة للزوار بحيث يمكنهم منح أنفسهم المزيد من الوصول، صحيح؟
أيضًا @nathank، ماذا يعني هذا؟
هل تقصد أن العضو لا يمكنه الربط المتبادل (على الإطلاق) من فئة أعضاء إلى أخرى إذا كانت مقيدة أمنيًا (على الإطلاق، أي أعضاء)؟ هذا ثمن باهظ!
أنا أعيد النظر في هذه النقطة ما إذا كان الأمر يستحق محاولة السماح للزوار المسجلين، من أجل الحصول على عملاء محتملين.
@denvergeeks بما أن مجتمعي سيكون مدفوعًا، ربما يمكنني ترقية استضافتي للوصول إلى إضافة Discourse Subscriptions. كنت أخطط لاستخدام ThriveCart نظرًا لأن دوراتي (اختياري، خارج المجتمع) سيتم دفع ثمنها من خلالها على أي حال، ويمكنني بعد ذلك تجميع الدورات والتدريب وعضوية المجتمع وما إلى ذلك، والاحتفاظ بجميع المعاملات المالية في مكان واحد.
نعم، الأمر بهذه البساطة.
لا يمكنك منح الوصول إلى فئة فرعية إلا إذا كانت المجموعة لديها أيضًا وصول إلى الفئة الأصلية؛ هذا يحمي من الخطر الذي تسلط الضوء عليه بشكل جيد.
ليس بهذا السوء - لا يزال بإمكانك الارتباط بشكل جيد، ولكن لن يتم إنشاء مربعات Oneboxes الجميلة.
للأسف، خارج الصندوق يتكامل فقط مع Stripe. وإلا لكان مثاليًا لك.
إعجاب واحد (1)
شكرًا @nathank لقد نشرت هذا كخطأ.
في هذه الأثناء، سيتطلب جزء من عمليتي تخصيص عضوية مجموعة “منتدى خاص” تلقائيًا لجميع المستخدمين الحاليين للمنتدى الخاص (حتى الآن، لم أكن أستخدم المجموعات بشكل صريح على الإطلاق، وكان المنتدى خاصًا افتراضيًا). لا أرى طريقة واضحة لتحقيق ذلك لا تتضمن إرسال دعوات (زائدة عن الحاجة) للانضمام، ومتطلبًا لكل مستخدم حالي للمنتدى للاستجابة، فقط للاحتفاظ بالوصول.
لدي شعور سيء بأن الطريقة الوحيدة لتحقيق ذلك تلقائيًا هي من خلال استعلام مستكشف بيانات سيء.
إعجاب واحد (1)
نعم، أستضيف بنفسي على Digital Ocean
لا داعي للشعور بالسوء!
إذا كان لديك قائمة بأسماء المستخدمين أو رسائل البريد الإلكتروني الخاصة بك (على سبيل المثال، من التصدير عبر /admin/users)، فيمكنك ببساطة نسخ هذه القائمة ولصقها في 
في صفحة المجموعة.
سهل للغاية!
من الذاكرة، يواجه صعوبة إذا كان لديك أكثر من 1000 مستخدم. ولكن يجب أن تكون بخير.
إعجاب واحد (1)
شكرا @nathank
بالنظر إلى الحوار، كما هو مكتوب، يبدو إلى حد ما وكأنه سينشئ دعوات لهؤلاء المستخدمين، بدلاً من نقلهم فعليًا؟
إنه ذكي بما يكفي لإضافة أولئك الذين لديهم حسابات حالية، وإرسال دعوات إلى أولئك الذين ليس لديهم.\n\n أنا أعرف لأنني طلبت ذلك! ولكن نعم، يمكن أن يكون النص أفضل، أليس كذلك؟\n\n اذهب واختبره مع عدد قليل من المستخدمين التجريبيين.
إعجاب واحد (1)
شكراً @nathank. لقد نجحت تمامًا كما قلت، ونعم إنها ذكية جدًا!
بكل سرور، تعرفت على نسخة من الحافظة في ويندوز لعمود منسق من عناوين البريد الإلكتروني من إكسل كفاصلة عند لصقها في مربع الحوار.
في حالتي، واجهت “خطأ 502” كثيرًا حتى عند لصق 500 مستخدم فقط في المرة الواحدة - يبدو أن هذه مشكلة اختناق في الخادم (خطة الاستضافة الخاصة بي لديها قيود على استخدام الشبكة ووحدة المعالجة المركزية).
تقليل ذلك إلى 200 مستخدم في المرة الواحدة نجح بشكل شبه ثابت، على الرغم من أنه إذا تركت وقتًا أطول بين الدفعات، يمكنني تجاوز عدد قليل آخر في المرة الواحدة.
خطوتي التالية الآن هي بطريقة ما الحصول على نوع من رابط المزامنة ثنائي الاتجاه بين متغير حقل المستخدم المخصص لـ “المنتدى الخاص” لتنفيذ أو منع الوصول إلى مجموعة “المنتدى الخاص”. لا يزال لا يوجد نجاح في القيام بذلك عبر Discourse Automation.
في الوقت الحالي، لا يزال حساب الاختبار الذي يسجل ويختار فقط مربع “المنتدى العام” يحصل على وصول كامل إلى كليهما.
حقول المستخدم المخصصة الجديدة الخاصة بي للوصول إلى المنتدى العام والخاص تظهر أيضًا في ملفات تعريف المستخدمين، والتي قد تكون مصدرًا للارتباك، خاصة وأن المستخدمين الحاليين لديهم هذه الحقول غير مملوءة.
قد يكون من الأفضل إذا كان الحقل مرئيًا للمسؤولين فقط، أو كان رماديًا لمستخدمي المنتدى العام فقط.
ما سيساعد كثيرًا هو وجود طريقة لمسؤول المنتدى لترشيح مجموعات المستخدمين التي يمكن الوصول إليها مباشرة أو تجاوزها، وبالتالي الفئات المعينة للمستخدم، مع الموافقة أولاً على المستخدمين - كل ذلك من نفس مربع حوار “الموافقة على المستخدم”.
في الواقع، يجب أن يكون ملف تعريف المستخدم بأكمله قابلاً للتحرير من مربع الحوار هذا - للسماح بتنظيف أخطاء المستخدم المحددة في حقول المستخدم المخصصة.
حاليًا، الطريقة الوحيدة لتنظيف مشكلات الملف الشخصي عند التسجيل تبدو وكأنها تتضمن الكثير من التنقل إلى مناطق أخرى بالإضافة إلى الموافقة على المستخدم - مع زيادة كبيرة في خطر الخطأ أو الإغفال من جانب المسؤول نتيجة لذلك.
حسنًا، تحديث
لقد نجحت أخيرًا في تشغيل Discourse Automation - كانت الحيلة هي استخدام نوع حقل مستخدم مخصص قائمة منسدلة (على الرغم من أن التعليمات لا توضح ذلك) بدلاً من نوع حقل مربع الاختيار الذي بدأت به. يجب أن تتطابق خيارات القائمة المنسدلة تمامًا مع أسماء مجموعات المستخدمين الكاملة
مهم جدًا - تأكد من أن هذا الحقل الجديد غير قابل للتحرير من قبل المستخدم بعد التسجيل، وإلا يمكن للمستخدم الذي يسجل ويتم الموافقة عليه فقط للمنتدى العام أن يمنح نفسه لاحقًا حق الوصول إلى المنتدى الخاص بشكل أحادي.
إعجابَين (2)
مرحباً @tgustilo
يبدو أنني تمكنت من حل الأمور دون اللجوء إلى أي إضافات خارجية.
إن إضافة الأتمتة المضمنة هي الوحيدة التي أستخدمها، وقد تم نشر نصيحة ومشكلة تتعلق بهذا الأمر أعلاه في هذا الموضوع.
لقد تخليت (في الوقت الحالي) عن مربع حوار تسجيل مستخدم مشروط حيث تختلف المعلومات التي يُطلب من المستخدم تقديمها اعتمادًا على المنتدى الذي يرغب في الوصول إليه. لذلك لا توجد إضافات تحقق من مصادقة Discourse أو الإضافات المخصصة للمعالج.
النتيجة ليست أنيقة تمامًا لمقدمي طلبات المنتدى العام، ولكن إلى حد ما ربما يكون هناك فائدة في الكشف عن معظم المؤهلات المهنية وحقول المستخدم المخصصة لدور العمل وما إلى ذلك المستخدمة لمقدمي طلبات المنتدى الخاص، لالتقاط أي مؤهلات مهنية وأدوار أخرى يحملها عضو الجمهور المتقدم، وعرض هذه المعلومات على ملفه الشخصي العام.
هذه المعلومات تعني أن أي شخص يتفاعل مع هذا الشخص لديه فهم أكبر لما قد يكون ذا صلة بمستواه ومجال خبرته.
من هنا، أود حقًا أن تكون هناك طريقة للمسؤول لتعديل طلب مستخدم مباشرة قبل الموافقة عليه - كل ذلك من نفس مربع حوار الموافقة.
بهذه الطريقة، يمكن منح الشخص الذي يحاول التقدم بطلب للوصول إلى المنتدى الخاص والذي من الواضح أنه لا ينتمي (بناءً على المعلومات الأخرى المقدمة)، عضوية في مجموعة مستخدمي المنتدى العام دون الحاجة إلى إعادة التقديم من البداية (مما يضيع هذا الجهد)، ويمكن تصحيح أي أخطاء واضحة أخرى في ضربة واحدة (ربما مع علامة مرمزة بالألوان تحذر المستخدم من حقول ملفه الشخصي المعدلة).
في الوقت الحالي، تتطلب معالجة المشاكل في ملفات تعريف المستخدمين المقدمة (بما في ذلك مجموعة المستخدمين التي اختارها المستخدم) إما رفض طلب المستخدم بشكل مباشر، مع القليل من الشرح أو بدونه، أو إجراء عملية تنظيف منفصلة متعددة الخطوات وعرضة للأخطاء، مع مخاطر عالية لحدوث أخطاء أو سهو من قبل المسؤول.
3 إعجابات
أود أن أجعل عملية تقديم الطلبات تعمل بهذه الطريقة لحالتي أيضًا، ويتم التحكم فيها بالكامل من خلال إضافة الأتمتة (Automation plugin)، وبشكل مثالي، كما تقول، أكون قادرًا على تعديل عضوية المستخدم في المجموعة، وحقول الملف الشخصي، وأي شيء آخر أثناء عملية الموافقة نفسها.
سيكون لتدفق عمل تقديم الطلبات والموافقة للمسؤولين حالات استخدام متعددة، بدءًا من معالجة الأعضاء العامين (أو الأعضاء التجريبيين، أو الأعضاء ذوي الوصول المحدود إلى المحتوى المجاني) وصولًا إلى إعداد أكثر تعقيدًا للأعضاء الخاصين أو المدفوعين أو الملتزمين.
أفكر أيضًا أنه سيكون من المفيد تصفية مختبري النسخة التجريبية الجيدين والأعضاء المبتدئين، وهو ما أواجهه حاليًا. أود خيارًا واسعًا ومفتوحًا لأي شخص مهتم، ولكني أحتاج حقًا إلى تصفية من سيصبح أعضاء أساسيين أو جوهريين أقوياء يتمتعون بالكثير من التأثير.
إذا كان شخص ما يبني مجتمع دعم لمرافقة عروض الدورات التدريبية أو التدريب، فيمكن لأتمتة التسجيل الأولية أيضًا توجيه هؤلاء الأشخاص إلى مجموعة مناسبة أو مجموعة تدريب/دعم.
لذلك هناك العديد من الاستخدامات لدمج التسجيل/تقديم الطلبات الآلي مع موافقة مرنة للمسؤول.
أتفق على أن القدرة على تكوين إضافة مجانية واحدة ورسمية، دون الحاجة إلى الدفع الإضافي، مفيدة للغاية للمجتمعات الناشئة التي لا تملك تمويلًا أو (أي/العديد من) العضويات المدفوعة.
شكرًا لمشاركة عمليتك. مفيدة جدًا.
إعجاب واحد (1)