السماح بتسجيل المستخدمين الجدد بشكل مشروط

مرحبًا،
أنا جديد في إدارة وتطوير Discourse، ولا أتحدث لغة Ruby (بعد – رغم أنني مستعد تمامًا للتعلم). كانت مهمتي الأولى هي إعداد تثبيت لـ Discourse، وقد قمت بذلك على Digital Ocean باستخدام صورة Docker الرسمية. حتى الآن، كل شيء يسير على ما يرام – شكراً للأشخاص الذين جعلوا الأمر سهلاً للغاية!

مهمتي التالية أكثر تحدياً (بالنسبة لي). تطوعت لإعداد هذا النظام لمنظمة غير ربحية ترغب في تقييد تسجيل المستخدمين ومشاركتهم على أعضاء تلك المنظمة فقط. لذا، أحتاج إلى تعديل أو دمج (أو استبدال؟) عملية إنشاء المستخدم الجديد بطريقة تسمح لنا بالتحقق برمجياً مما إذا كان عنوان البريد الإلكتروني المُقدَّم يتطابق مع عنوان أحد الأعضاء الحاليين في المنظمة، وما إذا كانت تاريخ انتهاء عضوية العضو يقع في المستقبل.

تستخدم المنظمة نظام NeonCRM، وهم يوفرون واجهة برمجية (API) تجعل عملية التحقق هذه معقولة السهولة. كما أفهم، توفر Discourse واجهة برمجية تسمح أيضًا بالقيام بأي شيء يمكنك فعله يدويًا. إذن، من الناحية النظرية، من الممكن تمامًا تنفيذ ما أريده، أليس كذلك؟ السؤال هو: ما هو أفضل نهج؟

على سبيل المثال، إذا سمحت Discourse بكتابة مستمع للأحداث (أو إضافة؟) يراقب عملية تسجيل مستخدم جديد، ويقوم بهذا التحقق، ويمكنه إلغاء التسجيل مع عرض رسالة توضيحية يمكنني إظهارها بطريقة ما (عذراً، يجب أن تكون عضوًا في رابطة XYZ) – فهذا سيكون رائعًا.

بديلًا عن ذلك، يمكنني تخيل كتابة صفحة تسجيل مستخدم خاصة بي (باستخدام لغة PHP التي أتقنها جيدًا) تستخدم كلتا الواجهتين البرمجيتين. لكن في هذه الحالة، سأحتاج إلى تعديل تثبيت Discourse بطريقة ما بحيث يعيد توجيه صفحة التسجيل إلى نسختي المخصصة.

لذا، سأكون ممتناً جدًا لسماع بعض الاقتراحات حول ما يجب أن يبدو عليه الاستراتيجية العامة، وأين يجب أن أبدأ في تعلم كيفية تنفيذ ذلك.

شكرًا جزيلاً!

إعجابَين (2)

يمكنك تقييد التسجيلات حسب نطاق البريد الإلكتروني، وإذا كان جميع مستخدميك يستخدمون نفس النطاق، فلن يتمكن أي شخص من خارج تلك المنظمة من الانضمام. في الإعدادات، ابحث عن allowed email domains.

قائمة بنطاقات البريد الإلكتروني المفصولة بالفاصلة العمودية (|) يجب أن يستخدمها المستخدمون لتسجيل حساباتهم. تحذير: لن يُسمح للمستخدمين الذين لديهم نطاقات بريد إلكتروني غير مدرجة في القائمة!

إعجابَين (2)

آه، قد يكون ذلك فعالاً إذا كان نطاق المجالات الممكنة محدودًا بحجم معقول، لكن في هذه الحالة، عناوين البريد الإلكتروني عشوائية. شكرًا على الاقتراح.

إعجابَين (2)

هل هذا يساعد؟

@Jonathan5 شكرًا لك على الاقتراح. لقد راجعت ذلك الموضوع، وبصراحة يبدو وكأنه كابوس. وعلاوة على ذلك، لا يستخدم أعضاء هذه الجمعية NeonCRM مباشرة لتسجيل الدخول إلى أي شيء، بل فقط مديرو الجمعية يفعلون ذلك. الأمر معقد.

تخطر لي فكرة أخرى. لقد قمت بإعداد Discourse ليكون مخصصًا للدعوة فقط. افترض أنني سأتركه على هذا النحو، لكنني سأعدل نص صفحة تسجيل الدخول ليقول شيئًا مثل: “يرجى التوجه إلى my.example.org/discourse-invitation لطلب دعوة.” وعند ذلك العنوان، سأضع سكريبت خاص بي يستخدم واجهة برمجة تطبيقات NeonCRM للتحقق من عضوية المستخدم المحتمل، ويستخدم واجهة برمجة تطبيقات Discourse لإنشاء المستخدم (في حال نجاح التحقق)، ثم يرسل له الدعوة. أعتقد أن تفكيري هنا سليم. هل أنا محق؟