يمكنني تكرار هذه المشكلة إذا قمت بتفعيل كل من SSO وإعداد الموقع “يجب الموافقة على المستخدمين”. للموافقة على المستخدم، انقر فوق اسم المستخدم في عنصر المراجعة:
سيؤدي ذلك إلى نقلك إلى صفحة إدارة المستخدم:
في قسم الأذونات بصفحة إدارة المستخدم، انقر فوق زر “تفعيل الحساب” إذا لم يكن الحساب قد تم تفعيله بعد:
ثم انقر فوق زر “الموافقة”:
يجب أن يؤدي ذلك إلى الموافقة على المستخدم وإزالة الإشعار من قائمة المراجعة الخاصة بك.
رائع. تم الإصلاح، شكراً لك. إذن هل هذا مقصود؟ لست متأكداً من فهمي لكيفية اندماج مفهوم التفعيل هنا. هل يجب أن أقوم بالتفعيل والموافقة في كل مرة؟
أعتقد أن تفعيل كل من SSO وmust approve users معًا يُعد حالة هامشية بعض الشيء. لست متأكدًا من كيفية عملها كما هو متوقع. مثاليًا، عند تفعيل SSO، يجب التعامل مع موافقة المستخدمين على موقع مزوّد SSO (WordPress). للأسف، يتطلب ذلك بعض الكود المخصص. راجع How to prevent some WP users from being able to login to Discourse للحصول على تفاصيل حول إعداد ذلك.
سأقوم بدراسة كيفية عمل موافقة المستخدمين كما هو متوقع عند تفعيل كل من must approve users وSSO معًا. وسأعود بالإبلاغ هنا إذا عثرت على أي شيء يستحق الذكر.
شكرًا لك على الرد الممتاز، @simon. لم أذكر هذا سابقًا لأنه كان مبنيًا فقط على استرجاع للذاكرة (والذي، في حالتي، مشكوك فيه دائمًا). ولكن…
لقد سجل مستخدم آخر للتو الدخول، وظهرت لي فورًا خيار الموافقة، أي أنه لم يكن هناك حاجة للمرور عبر مرحلة التفعيل أولًا.
لذا، لا يزال هذا الأمر محيرًا جدًا بالنسبة لي. لم أقم بأي تغيير في الإعدادات يفسر سبب اختلاف العملية بين الشخصين الجديدين الأخيرين. يسود الارتباك…
سأبلغك إذا اكتشفت المزيد.
شكرًا مرة أخرى.
كنت أظن أن هذا غير مسموح به. فمضيف SSO هو المسؤول عن إدارة المستخدمين. وفهمي هو أنه إذا كنت بحاجة إلى بعض المستخدمين الذين لديهم حسابات على SSO ولا يجب أن يكون لديهم وصول إلى Discourse، فيجب عليك إدارتها عبر المجموعات أو منع تسجيل الدخول إلى Discourse بطريقة ما.
على الرغم من أننا نواجه غرابة تتمثل في ضرورة تفعيل و اعتماد بعض المستخدمين على حد سواء بعد محاولتهم تسجيل الدخول، إلا أن النظام يبدو أنه يعمل بشكل صحيح. مع الإعدادات الحالية، يجب على المدير اعتماد الطلبات بعد كل محاولة تسجيل دخول للمستخدم لأول مرة. هذا أمر مقبول (إلى حد ما - انظر أدناه)، لذا يبدو أن الإعدادين (استخدام SSO واعتماد المستخدمين) مناسبان.
ومع ذلك، فإن عدم القدرة على اعتماد مجموعة من المستخدمين مسبقًا، قبل أن يحاول المستخدم تسجيل الدخول لأول مرة، أمر مؤسف ويشكل مشكلة كبيرة. هذا يعني أن المستخدم يضطر للانتظار قبل أن يتمكن من تسجيل الدخول، رغم أننا (المديرون) على دراية تامة بهويتهم مسبقًا.
أظن أن @simon محق في اعتبار هذه حالة هامشية من منظور Discourse. ومع ذلك، فإن بيع المنتجات العادية والعضويات في مواقع WooCommerce هو أمر شائع جدًا. وأنا في هذه الحالة، وهي سيناريو شائع جدًا. لذا، فإن مستخدمين ينقسمون إلى مجموعتين (متداخلتين) منطقيتين: العملاء والأعضاء. أريد أن أتمكن من اعتماد قائمة الأعضاء مسبقًا حتى لا يضطروا للانتظار للحصول على الموافقة. قد ألجأ إلى أتمتة هذه العملية لاحقًا، لكن ذلك سيكون بعد إطلاق المنتدى في الأول من سبتمبر، وهو أمر مؤسف.
أهًا! أنت تريد تكوين WooCommerce لإدارة هذه المجموعات في Discourse، بدلاً من التعديل اليدوي على هؤلاء المستخدمين في Discourse. هناك بعض المواضيع حول كيفية القيام بذلك. يتطلب الأمر بعض الكود المخصص، وهناك أمثلة متاحة. كمرجع، عادةً ما أطلب مبلغًا يتراوح بين 1000 و1500 دولار مقابل هذه الخدمة.
شكرًا لك @pfaffman. ربما أستطيع القيام بذلك بنفسي مع مرور الوقت، وقد كنت أقوم بالبحث. بالنسبة للإطلاق، سأضع توقعًا بأنه سيكون مطلوبًا الحصول على موافقة، وسأحاول معالجة هذه الحالات بسرعة. بعد الإطلاق، سأرى ما إذا كان بإمكاني أتمتة هذه العملية بطريقة ما.
توضيح بخصوص شيء واحد يتعلق بآمالي في الحل المؤتمت بالكامل.
أود تجنب الحل الذي يسمح لغير الأعضاء بتسجيل الدخول فعليًا، ثم يتم منعهم من القيام بأي شيء (ربما لأنهم غير مدرجين في مجموعة تتعلق بالأعضاء). بدلاً من ذلك، إذا لم يكن الشخص عضوًا، أود أن يفشل تسجيل دخوله فعليًا، ويفضل أن يكون ذلك مع إمكانية إعادة التوجيه إلى صفحة يمكنني فيها شرح السبب.
وبعبارة أخرى، يُفضل منع تسجيل الدخول إذا لم يكن الشخص عضوًا، بدلاً من السماح بتسجيل الدخول ثم منع الوصول إلى الموارد.
شكرًا مرة أخرى.
@سيمون، لقد خصصت بضع دقائق للبحث عن خيارات ممكنة لهذا التحدي، واكتشفتُ وجودك في هذه الصفحة 
WP Discourse – WordPress plugin | WordPress.org. لذا، لديّ سؤال أكثر تحديدًا لك بخصوص هذا الملحق.
تدور أعمالنا حول ووردبريس وووكومرس، وتميل جميع التكاملات التي أقوم بها إلى استخدام الوسوم، حيثما أمكن، لإدارة المستخدمين. يُعد WP Fusion الرابط الذي يجمع كل هذا معًا، لكن الخلاصة هي أن لدي وسومًا لجميع المستخدمين (سواء كانوا عملاء أو أعضاءً، إلخ).
في ضوء هذا السياق، ما أودّ فعله حقًا هو كتابة دالة خاصة بي على جانب ووردبريس تنفذ بعض المنطق (في حالتي، ببساطة التحقق من وجود وسم لدى المستخدم) وترفض تسجيل الدخول إذا لم تُستوفَ هذه المعايير.
هل تعرف من رأسك ما إذا كان هناك أي خطاف (hook) يمكنني استخدامه لتنفيذ هذا المنطق؟ سيكون ذلك حلاً رائعًا ويترك عملية تسجيل الدخول بيد ووردبريس إلى حد كبير.
شكرًا لك.
نعم، يصف هذا الموضوع كيفية القيام بما تبحث عنه: How to prevent some WP users from being able to login to Discourse. يحتوي المنشور الثاني في الموضوع على دالتين مثاليتين يمكنك استخدامهما. ستحتاج إلى توفير الكود لاستبدال التعليق /* بعض الشرط الذي يعيد قيمة صحيحة إذا لم يستوفِ المستخدم شرط العضوية */ الموجود في مثال الكود.
رائع!! أعتقد أنني أسأت فهم ذلك الموضوع عندما تصفحته سابقًا، لكنه يبدو أنه تمامًا ما أحتاجه. في انتظار التنفيذ والاختبار (كلمات أخيرة مشهورة!) أعتقد أنني جاهز!
شكرًا لك.
ظننت ذلك… و…
أخبرتك بذلك! 
يسعدني أنك في الطريق الصحيح لحل المشكلة.
بالفعل. أعتذر عن إغفالي ذلك، @pfaffman، وأشكرك على مساعدتك. سأقوم الآن بإعداد خادم VPS من نوع Discourse يعكس موقعي الإلكتروني المعكوس، وبإذن الله، آمل أن يكون ذلك جاهزًا للعمل قريبًا.
