تم تعطيل تسجيل الدخول المحلي (تم تكوين تسجيل الدخول عبر فيسبوك وجوجل)
يجب أن يوافق الموظفون على جميع حسابات المستخدمين الجديدة
لدينا قائمة بريدية كبيرة ونود “الموافقة المسبقة” على جميع عناوين البريد الإلكتروني في هذه القائمة. إذا وصل شخص إلى الموقع وحاول التسجيل أو تسجيل الدخول باستخدام حساب فيسبوك أو جوجل مرتبط ببريد إلكتروني موجود في قائمة الموافقة المسبقة، فلن يحتاج إلى انتظار موافقة أحد الموظفين وسيتمكن من بدء استخدام الموقع فورًا.
نأمل أيضًا أن نتمكن من تكوين عضوية المجموعات مسبقًا لكل بريد إلكتروني.
هل هذا ممكن؟ الحلول التي تتطلب استخدام واجهة برمجة تطبيقات Discourse موضع ترحيب.
أخشى أن هذا لن ينجح على الإطلاق!
ويرجع ذلك أساسًا إلى أن الدعوات لا تعمل ما لم يتم تمكين تسجيل الدخول المحلي. لذا، فمن المرجح أنك بحاجة إلى إضافة مخصصة للغاية تتولى كل هذا، أو نظام مصادقة خارجي يلبي متطلباتك.
أعتقد أنه إذا قمت باستيراد العناوين عبر سكريبت استيراد، فسيتم تطبيق الإجراء الصحيح. ستحتاج إلى التأكد من عدم تحديد هؤلاء المستخدمين كـ «نشط» إلا إذا كنت ترغب في المخاطرة بإغراقهم بالإشعارات والملخصات.
يجب أن يكون هذا أمرًا سهلاً نسبيًا من خلال وحدة التحكم. أعتقد أنه يمكن تنفيذه عبر واجهة برمجة التطبيقات (API) إذا كنت مستضافًا في مكان ما.
تعني “كبير” حوالي 5,000 مستخدم - وهو عدد لا نرغب في إدخاله يدويًا في واجهة المستخدم في مكان ما.
@pfaffman هل يمكنك توضيح كيفية إنشاء المستخدمين عبر واجهة برمجة التطبيقات (API)؟ يبدو أن حقل “كلمة المرور” إلزامي لإنشاء المستخدمين، وأعتقد أن هذا لا يمكن تنفيذه إذا كان تسجيل الدخول المحلي معطلًا: POST /users
للتوسع قليلًا في حالة الاستخدام، بالنسبة للآخرين الذين قد يفكرون في شيء مماثل: نرغب في تشجيع المستخدمين على تسجيل الدخول باستخدام حساباتهم على وسائل التواصل الاجتماعي - فكثير من الأشخاص الذين نعمل على إشراكهم في Discourse ليسوا ملمين بالتكنولوجيا، ونريد أن يعرفوا أنهم لا يحتاجون إلى إدارة اسم مستخدم وكلمة مرور آخرين.
ومع ذلك، تتطلب ميزة الدعوة عبر البريد الإلكتروني الحالية في Discourse من المستخدم اختيار كلمة مرور، مما يقوض هدفنا المتمثل في الحفاظ على بساطة الأمور لمستخدمينا.
ربما توجد طريقة مختلفة لتحقيق هدفنا؟ لست ضد تمكين تسجيل الدخول المحلي إذا لزم الأمر، لكنني أريد أن يرى المستخدمون المدعوون بوضوح أنه يمكنهم تسجيل الدخول عبر وسائل التواصل الاجتماعي دون الحاجة إلى كلمة مرور على الإطلاق.
شكرًا لكم جميعًا! أنا متحمس حقًا لزيادة عدد الأشخاص الذين يستخدمون Discourse.
السماح لهم بعدم إنشاء كلمة مرور مع إلزامهم بإخبارك بعنوان البريد الإلكتروني الذي يستخدمونه لتسجيل الدخول عبر وسائل التواصل الاجتماعي ليس هو نفسه. فلا يزال بإمكانهم تخطي إنشاء كلمة مرور إذا استخدموا تسجيل الدخول عبر وسائل التواصل الاجتماعي. غالبًا ما أرفض تسجيل الدخول بحساب Gmail الخاص بي (على الرغم من أن ذلك أصبح أقل تكرارًا الآن)، ورفضت زوجتي ذلك في الغالبية العظمى من الأحيان. كما أن تسجيل الدخول عبر البريد الإلكتروني مفيد جدًا ويعني أنك لن تحتاج أبدًا إلى كلمة مرور. لكني أشتت الانتباه.
إذا كانت واجهة برمجة التطبيقات تتطلب كلمة مرور، فقم ببساطة بإنشاء كلمة مرور عشوائية. وجود كلمة مرور لا تعرفها ولا تحتاجها يكاد يكون مكافئًا لعدم وجود كلمة مرور على الإطلاق.
في مرحلة ما، قمت بإنشاء https://github.com/pfaffman/discourse-user-creator؛ لا أضمن أنه يعمل، لكنه يجب أن يقربك من الحل. أنت تريد إنشاء مستخدمين غير مفعّلين، لذا ستحتاج إلى تعديله، لكن يجب أن يكون واضحًا جدًا ما الذي يجب إزالته. (إذا كنت تريد ببساطة حل المشكلة ولديك ميزانية، فلا تتردد في الاتصال بي.)
يجب أن أعترف أنني لم أدرك حتى التدقيق الدقيق أن حقل كلمة المرور اختياري للمستخدمين الذين يقبلون دعوات البريد الإلكتروني. أنت على حق في أن المستخدمين يجب أن يكونوا قادرين على اختيار ما إذا كانوا يريدون استخدام بريد إلكتروني مختلف وإنشاء كلمة مرور. سأشعر براحة أكبر بكثير إذا كان واجهة المستخدم أوضح بأن كلمة المرور اختيارية، خاصة عند تمكين تسجيل الدخول عبر وسائل التواصل الاجتماعي في الموقع. مع واجهة المستخدم الحالية، سيحتاج شخص ما إلى عدم الرغبة حقًا في إنشاء كلمة مرور لاكتشاف أن هذا ليس مطلوبًا بشكل صارم، في رأيي. أعتقد أنني يجب أن أتدحرج وأقوم بإنشاء طلب سحب (PR) لتحسين تجربة المستخدم
نظرت إلى كود المثال، شكرًا لك! وبالنسبة لما يستحقه، كنت بحاجة إلى استخدام هذه الحيلة لإجراء مكالمات API المناسبة: Using the API to create a user on an SSO only system - #13 by DylannCordel - ومع ذلك، لا أعتقد أن هذا يلبي حالة الاستخدام التي كانت في ذهني لأنه يحفز إرسال بريد إلكتروني للمستخدم للتفعيل، وهو ما كنت أتمنى تجنبه لصالح تجربة سلسة “تعمل مباشرة” إذا/عندما يأتيون في النهاية لتسجيل الدخول إلى الموقع.
لعبت أيضًا قليلاً مع هذا الحل: How to manually add user in discourse? - #10 - أعتقد أنه سيعمل على إضافة حسابات المستخدمين التي أريد أن توجد باستخدام هذه الطريقة، لكن في النهاية لست متأكدًا مما إذا كان الأمر يستحق المخاطرة بالنسبة لي لتعديل البيئة داخل الحاوية مباشرة لإجراء هذه التعديلات.
لذلك، وبشكل عام، أعتقد أن سير العمل الذي كنت أتمناه ليس حقًا سير عمل مدعومًا أو متوقعًا، وسأضطر إلى الرضا بذلك حتى يتم تحسين واجهة المستخدم (ربما) في مرحلة ما.
تسجيل الدخول عبر وسائل التواصل الاجتماعي يتجاوز كلمة المرور لأن المصادقة تتم عبر فيسبوك، تويتر، جوجل، وغيرها.
الدعوات تجعل كلمة المرور اختيارية مؤقتًا، لكنك يجب أن تتبع رابط الدعوة مرة أخرى لتسجيل الدخول، وهو ما نعتقد أننا قيدناه لدرجة أنه لم يعد يعمل فعليًا. ستحتاج إلى طلب إعادة تعيين كلمة المرور عبر البريد الإلكتروني للدخول بعد ذلك، وهو ما يتطلب تعيين كلمة مرور.
القصة طويلة، لكن الدعوات صُممت لإدخال الأشخاص والرد فورًا بأقل قدر من التعقيد، لكنها ليست مخصصة للسماح للأشخاص بتخطي تعيين كلمة مرور إلى الأبد.
إرسال دعوة عبر البريد الإلكتروني إلى مستخدم (يجب تفعيل تسجيل الدخول المحلي ليكون هذا الخيار متاحًا).
عندما يضغط المستخدم على الدعوة، يمكنه ترك حقل كلمة المرور فارغًا وتسجيل الدخول فورًا.
في المرة التالية التي يزور فيها الموقع ويحتاج فيها إلى تسجيل الدخول، يمكنه استخدام حساب على شبكة اجتماعية يتطابق مع عنوان بريده الإلكتروني.
الآن، من الإنصاف القول إن هذا ربما لا ينبغي أن يعمل، وأن تعليقي السابق حول واجهة المستخدم غير الواضحة قد يكون في الواقع ميزة وليس عيبًا مصممًا لثني الأشخاص عن استخدام هذه الطريقة البديلة. ومع ذلك، يبدو أن هذا مسار مقبول للمستخدم الذي يتم دعوته عبر البريد الإلكتروني لكنه لا يريد في النهاية إنشاء كلمة مرور ويفضل الفوائد الأخرى لتسجيل الدخول عبر الشبكات الاجتماعية (مثل نقل صورة ملفه الشخصي).
أتفهم تمامًا النقطة السابقة التي تشير إلى أن بعض المستخدمين يفضلون فعليًا وجود كلمة مرور بدلاً من تسجيل الدخول عبر الشبكات الاجتماعية، وأنا مقتنع بأنه لا ينبغي لي تعطيل هذه الميزة للأشخاص الذين يرغبون فيها. ومع ذلك، لا يزال أملُي معقودًا على وجود مسار سهل وواضح لدعوة المستخدمين أو إعدادهم بطريقة أخرى، خاصة أولئك الذين يفضلون عدم وجود كلمة مرور.
