متابعة للمناقشة من إضافة المستخدمين تلقائيًا إلى المجموعة بناءً على جزء من نطاق البريد الإلكتروني:
اقتراح
في الوقت الحالي، إعداد عضوية المجموعة “سيتم إضافة المستخدمين الذين يسجلون بنطاق بريد إلكتروني يطابق تمامًا أحد هذه النطاقات في هذه القائمة تلقائيًا إلى هذه المجموعة” – حيث يريد المسؤول مطابقة example.com – يطابق فقط النطاقات من المستوى الثاني مثل email@example.com.
أقترح تغيير هذا لمطابقة النطاقات الفرعية أيضًا، على سبيل المثال email@sub.example.com.
السبب/الفوائد
-
لن يكون من الممكن بالنسبة لي كتابة النطاقات الفرعية يدويًا لنطاقين متعلقين بالحكومة على وجه الخصوص: لكل منهما مئات النطاقات الفرعية، والتي تتغير باستمرار، والقائمة الكاملة ليست متاحة للجمهور.
-
سيوفر تناسقًا مع
email_domains_whitelist، كما لاحظ @sam في Automatic registration domain wild card - #3 by sam
نعم هناك عدم اتساق داخلي، عضوية مجموعتنا التلقائية تستند إلى مطابقة نطاق صارمة وفقًا لـ:
يستخدم المطابق الخاص بنا لـ
email_domains_whitelistهذه المطابقةأعتقد أنه من المنطقي جعل هذا متماسكًا ومتسقًا.
@techAPJ هل يمكنك تعديل تعبير المجموعة النمطي … بعناية والتأكد من اختباره للسماح أيضًا بالنطاقات الفرعية.
الحلول المقترحة
هذا ممكن من خلال تعديل طفيف لـ pattern = \"@(#{domains.gsub('.', '\\.')})$\" في discourse/discourse/blob/20de49c8722f8e50e93732702a8d06570376edcd/app/models/group.rb#L1017
-
تغيير هذا إلى
pattern = \"@.*(#{domains.gsub('.', '\\.')})$\"نجح معي عندما اختبرته على منتدى الخاص بي. -
أتخيل أن
pattern = \"@(.+\\\\.)?(#{domains.gsub('.', '\\.')})$\"(بناءً علىemail_domains_whitelist) سيعمل أيضًا ولكني لاحظت ذلك لاحقًا ولم أختبره. لا أفهم لماذا ليس(.+\\.)?ولكن ربما\\\\هو شيء خاص بـ Ruby.
بديل (إذا كنت قلقًا بشأن المستخدمين الذين يقصدون حاليًا استبعاد النطاقات الفرعية من العضوية التلقائية) هو السماح بالرموز البديلة، على سبيل المثال كتابة *.domain.com للعضوية التلقائية في المجموعة.
شكرًا
شكرًا للنظر في هذا الطلب.