عندما ينضم مستخدم جديد عبر رابط دعوة، أجد أنني بحاجة أيضًا إلى الموافقة على المستخدم في الوقت الحالي.
هذا يقوض الغرض الكامل من الدعوة؛ قد أرسل لهم رابط المنتدى.
لقد جربت هذا لمجموعة متنوعة من المواقف (رابط جديد، رابط قديم، شخص واحد، متعدد) في أكثر من مثيل واحد، وهو نفس الشيء.
لقد قمت بتعيين /admin/site_settings/category/all_results?filter=must_approve_users على TRUE لهذه الحالات. يبدو أنه يأخذ الأمر حرفيًا أكثر من اللازم! أريد فقط الموافقة على أولئك الذين ينضمون بدون دعوة، وهو ما كانت عليه الأمور سابقًا.
اعتقدت أن الدعوة من الموظفين هي موافقة صريحة - خاصة إذا كانت تتضمن عنوان البريد الإلكتروني للمستخدم!
مع دعوة مفتوحة، هناك بالطبع فرصة كبيرة لإساءة استخدام الرابط. ولكن يجب على الموظف إعداد الرابط عمداً للسماح بذلك، ويمكنه تحمل المسؤولية عن (وتقليل) هذا الخطر بسهولة.
هذا يعني أيضًا أن الأشخاص الذين يعثرون على موقعي لا يمكنهم الانضمام إليه ويتم استبعادهم ما لم يتمكنوا من العثور على شخص لدعوته. هذا سيء.
اقتراح
ماذا عن إضافة خيارين إلى /admin/site_settings/category/all_results?filter=must_approve_users؟
يجب على الموظفين الموافقة على جميع المستخدمين
ما لم تتم الدعوة من قبل الموظفين، يجب الموافقة على المستخدمين
لدينا نسخة تستخدمها مؤسسة خيرية/نقابة للتدريب على المهارات وقد تأثرت بشكل مماثل.
قبل التغيير، كان الموظفون يدعون المستخدمين لتجاوز الموافقة، والآن يتعين عليهم القيام بكلاهما. مع الحاجة إلى العودة والتحقق من كل موافقة مقابل قوائم الأعضاء، فقد زاد عبء العمل الإداري عليهم بشكل كبير.
أتساءل عما إذا كانت الحالة الحافة الرئيسية هي مجرد السماح بتجاوز إعداد “يجب الموافقة على المستخدم” إذا كان الدعوة تحتوي على عنوان بريد إلكتروني محدد فيها، والاحتفاظ بإعداد “يجب الموافقة على المستخدم” لروابط الدعوات المجهولة - ولكن قد يكون الأمر أكثر تعقيدًا في الواجهة الخلفية للقيام بذلك مما أتخيله.
هذا منطقي بالنسبة لي، خاصة إذا كانت الدعوة موجهة إلى عنوان بريد إلكتروني محدد وتم إرسالها من قبل الموظفين. لا أتخيل الحاجة إلى مستوى ثانٍ من الموافقة في هذا السيناريو.
ماذا عن السماح للمسؤولين فقط بتعيين علامة “الموافقة التلقائية” وتحديدها اختياريًا إلى “البريد الإلكتروني دون تغيير” أو “مقيد بواحد” أو شيء من هذا القبيل؟ في حالتي، سأكون سعيدًا حتى بوجود دعوة عبر سطر الأوامر يمكنها إنشاء هذه الدعوات الخاصة المعتمدة مسبقًا، هل هناك شيء كهذا متاح؟
لقد نشرت دعوة إلى منتدانا على نطاق واسع، وهذا يعمل بشكل جيد.
المشكلة هي بالنسبة لـ “المارة” الذين يعثرون على الموقع عبر بحث جوجل أو ما شابه. يتعين عليهم إرسال بريد إلكتروني للحصول على رابط انضمام، وهذا أمر مزعج للغاية للمسؤول.
اقتراح أرمان بسيط للغاية ولا أعتقد أنه سيكون من الصعب تنفيذه (أو أن يكون به ثغرات):
في الوقت الحالي، هذا ببساطة ليس هو الحال إذا كان must_approve_users مضبوطًا على TRUE:
في كل مرة يكون لدينا مجموعة من الأشخاص لدعوتهم، إما أن نقبل الكثير من الاحتكاك (خطوة الموافقة) أو نضطر إلى إعادة تكوين الموقع مؤقتًا (وإغلاقه أمام التسجيلات العامة)، وهو أمر مؤلم للغاية.
مرحباً، أود أيضاً أن أطلب إضافة ميزة لدعوات الموظفين لتجاوز خطوة الموافقة، ربما عن طريق قيمة منطقية اختيارية في مربع حوار إنشاء الدعوة.
في الوقت الحالي، عبارة “شارك هذا الرابط لمنح الوصول الفوري إلى الموقع” ليست صحيحة على الإطلاق للمواقع التي تكون فيها must_approve_users (يجب الموافقة على المستخدمين).
لتلخيص الأمر، هذا الطلب هو حتى يتمكن الموظفون في موقع must_approve_users من إنشاء رابط دعوة يتجاوز خطوة الموافقة. على الرغم من أن الموقع الذي أديره يتطلب الموافقة، إلا أننا نرغب أحيانًا في أن نكون قادرين على “الموافقة المسبقة” على المستخدمين عبر رابط دعوة نعلم أنه سيتم مشاركته بشكل خاص مع أفراد موثوق بهم، أو عندما نشارك الرابط في حدث مادي يتعلق بمجتمع المنتدى. (لا نعرف بالضرورة عناوين البريد الإلكتروني المفضلة لهؤلاء المدعوين لذلك لا يمكننا استخدام دعوة جماعية).
مع مواقعنا الكبيرة (إلى حد ما) التي تتطلب موافقة المستخدمين (must_approve_users)، يظل هذا الأمر مزعجًا في كل مرة نعقد فيها حدثًا فعليًا.
المشكلة هي أننا لا نستطيع ببساطة منح الأشخاص رمز QR جميلًا أو دعوة أو رابطًا للانتقال مباشرة إلى مثيلنا. على الأقل ليس بدون حل بديل قبيح بعض الشيء.
الحل البديل ومشكلاته
إيقاف تشغيل must_approve_users وجعل الموقع invite_only ليس مرضياً حقًا لأن:
يبدو أن العديد من الأشخاص يفسدون أي عملية دعوة ويحاولون الدخول من خلال “الباب الأمامي” (المغلق الآن).
الضجة التي يخلقها الحدث تنتقل بشكل عام إلى غير المدعوين أيضًا - ولكن لا يمكنهم التقدم للانضمام أيضًا.
لقد جعل الوضع الحالي منذ التغيير الأمور أكثر صعوبة بالتأكيد. اختارت المؤسسة الخيرية لتدريب المهارات التي عملت معها والتي تأثرت بشدة إغلاق مجتمعها بعد عدة أسابيع.
إنها مجرد تكاليف إدارية إضافية كثيرة جدًا عندما يكون لديك مئات الأشخاص يأتون ويذهبون كل أسبوع.
شكراً لإثارة هذا الموضوع مرة أخرى. أعتقد أننا وصلنا إلى القاعدة الثالثة هنا وأن بعض الإصلاحات مطلوبة لجعل الدعوة أسهل وأكثر سلاسة. لقد أثبت نظام الدعوة أنه من الصعب تغييره لأن الجميع يبدو أنهم يستخدمونه بشكل مختلف. سنرغب في الحصول على تعليمات واضحة وتجنب كسر سير عملهم.
سأتحقق مع الفريق وأرى ما يمكننا إدارته.
هذا خبر جديد بالنسبة لي، دعنا ننظر في ذلك بشكل منفصل.
قلقنا هو أنه يمكن إعداد المواقع بطرق عديدة مختلفة ثم توقع أن يعمل نظام الدعوات بطرق مختلفة أيضًا. الأمن مصدر قلق حقيقي. لذلك سنتعامل بحذر عند إجراء أي تغييرات أخرى على نظام الدعوات.
شعوري الشخصي هو أن النهج التالي سيكون الأفضل، لأنه لا يعتمد على إعداد المسؤول ويجعل السلوك واضحًا تمامًا مباشرةً في نافذة الدعوة. سيكون من الصعب حتى على شخص جديد تمامًا على discourse إنشاء رابط دعوة ومشاركته عن طريق الخطأ والذي يقوم بشيء لا يتوقعونه. ما رأيكم جميعًا؟
عند تمكين إعداد المسؤول يجب الموافقة على المستخدمين
يتم عرض تبديل للموظفين في نافذة الدعوة لإنشاء دعوة تتجاوز متطلبات الموافقة. على سبيل المثال [ ] لا تتطلب موافقة الموظفين
الدعوات التي يتم استردادها عند تحديد التبديل في (2) تسمح للمستخدم بالدخول إلى الموقع دون الحاجة إلى موافقة
الافتراض هو أن الموظفين فقط يجب أن يكون لديهم حق الوصول إلى هذا التبديل، لأن الغرض من إعداد يجب الموافقة على المستخدمين هو منح الموظفين السيطرة على من يُسمح له بالانضمام إلى المجتمع.
إذا كان هناك طلب كافٍ لذلك، يمكننا لاحقًا النظر في إضافة إعداد مسؤول لتحديد من لديه حق الوصول إلى هذه الميزة حسب المجموعة.
ذهب سام إلى حد وصف التغيير بأنه معقد بشكل مدهش. لا أشك فيه.
من الواضح أن الجهد الإجمالي للتغيير الأصلي بالإضافة إلى هذا سيكون أكبر مما لو تم النظر في هذا منذ البداية. لقد أثبتنا في ذلك الوقت أنه بينما وجدت إحدى المجتمعات أن الإعداد الافتراضي الحالي غير مقبول، كانت هناك عدة مجتمعات تعتمد على هذا السلوك. على سبيل المثال، لم تتخذ النقابة التي تخلت عن موقعها التدريبي للمهارات القائم على Discourse القرار باستخفاف، لكن كان من غير العملي بالنسبة لهم الاستمرار بمجرد ضياع المتدربين الذين دعاهم الموظفون في مجمع الموافقات العام.
إذا كانت المشكلة هنا هي نقص الفهم الصريح، فربما تكون هناك حاجة إلى خطوة وسيطة بين “يجب الموافقة على المستخدمين” ونموذج الدعوة الذي يقدم خيارًا لدعوات الموظفين لتجاوز الموافقة، وإلا فإن الشكوى الأصلية التي أدت إلى هذا التغيير قد تنشأ مرة أخرى.
لذلك، أشبه بـ:
عند تمكين إعداد المسؤول “يجب الموافقة على المستخدمين” وتغيير “دعوات الموظفين تتجاوز الموافقة” الجديدة من قيمتها الافتراضية “أبدًا”:
إذا كانت “دائمًا” فسيتم تطبيق السلوك القديم.
إذا كانت “اختياري” فسيتم عرض المفتاح في النموذج لإعطاء خيار تجاوز الموافقة اللاحقة.
بدون الخطوة الوسيطة، لا يكون المسؤولون على دراية كاملة بتداعيات “يجب الموافقة على المستخدمين”، وستحل بعض التفاصيل الدقيقة المشكلة الأخرى عند نسيان استخدام المفتاح.
أعتقد أن ذلك سيعمل بشكل جيد للغاية (ربما مع تعديل @Stephen أيضًا) - وأحب أنه نهج يركز على الأشخاص ولن يكسر أي شيء لأنه سيترك الآليات الافتراضية سليمة تمامًا.
حالة حافة ذات أهمية فائقة بالنسبة لي هي دعوات البريد الإلكتروني التلقائية المتعلقة بدعوات المجموعات. هذا يسمح بإضافة الأشخاص إلى مجموعة أو إرسال دعوة لهم اعتمادًا على ما إذا كانوا قد سجلوا بالفعل عبر إجراء إداري واحد. شخصيًا، أحتاج حقًا إلى تغطية هذا بطريقة ما أيضًا.
