لقد قدمت بعض الخلفية حول حالة الاستخدام في Restrict exposure of full name to certain groups. نحن نستخدم Discourse لتسهيل المناقشة حول التعليم العام المحلي؛ قاعدة المستخدمين المستهدفة هي في المقام الأول الآباء وأعضاء المجتمع المحلي الآخرين. نريد تحقيق توازن:
من ناحية، اجعل الموقع مفتوحًا للتصفح المجهول (حتى تتمكن محركات البحث من فهرسته، بحيث يمكن الوصول إليه حتى من قبل غير الأعضاء، بحيث يكون مفتوحًا/شفافًا من حيث المبدأ، …)
من ناحية أخرى، تجنب إتاحة المعلومات التعريفية الشخصية بشكل غير ضروري للمتتبعين وغير الأعضاء الذين يزورون الموقع - نريد السماح للأشخاص بمشاركة أسمائهم داخل المجتمع ونريد معالجة التردد الذي يشعر به الكثير من الناس في القيام بذلك.
في الأصل، بدا أن تعطيل “عرض الاسم في المشاركات” وتمكين “إخفاء ملفات تعريف المستخدمين عن الجمهور” سيعالج حظر تسرب الأسماء للمستخدمين المجهولين - ولكن بعد ذلك أدركنا أن ذلك لا يحدث. (وقد وعدنا الناس بالفعل عبر شروط الخدمة والأسئلة الشائعة بذلك. )
إن رفض الوصول إلى الاسم الكامل للمستخدمين المجهولين فقط سيؤدي إلى إنجاز المهمة. ولكن، نظرًا لأنه من السهل بنفس القدر ربط الوصول بالعضوية في المجموعة، أعتقد أنه يمكن القيام بذلك - مما يفتح إمكانية، على موقعنا، لتقييد الوصول إلى >=TL1، وهو أفضل من ذلك. (حاليًا، نطلب دعوة للتسجيل، ولكننا نريد التخلص من ذلك.)
بالنظر في هذه المشكلة/الموضوع، رأيت إشارات أخرى لطلبات مماثلة أو متشابهة، على سبيل المثال، “نريد فقط أن تكون مجموعة كذا وكذا قادرة على رؤية الأسماء”… لذا فإن هذا سيعالج تلك الاستخدامات أيضًا.
سؤال لك (قد تعتبره سؤال منتج!):
هل الإعداد enable_names يعني “لا تعرض الأسماء الكاملة للمستخدمين.” أم بالأحرى “هذا الموقع لا يستخدم الأسماء الكاملة، على الإطلاق.”؟
لدي شعور (من الكود نفسه، ومن مواضيع/مشاكل مثل هذه) بأن هناك نقصًا أساسيًا في الوضوح حول هذه النقطة - وقد فهمها البعض بطريقة، والبعض الآخر بطريقة أخرى.
موافق. يجب أن يكون للمسؤولين القدرة على الوصول إلى الاسم الكامل دون الحاجة إلى تشغيل وإيقاف المؤشر. هناك أسباب مهمة بشكل خاص (على الأقل لمنتدانا) لإخفاء الأسماء الحقيقية.
شكرًا لكل من ساهم في هذا الموضوع. أود فقط أن أسأل باحترام عما إذا كانت هذه المشكلة ستتم معالجتها في إصدار قادم - أو على الأقل الاعتراف بها كتراجع معروف.
تعطيل تمكين الأسماء حاليًا يكسر وظائف إدارة رئيسية بطريقة تبدو غير مقصودة، والافتقار إلى الوضوح حول ما إذا كان هذا عن قصد أو خطأ يجعل من الصعب علينا التخطيط. بالنسبة لأولئك منا الذين يديرون مواقع إنتاج حيث يتم تفضيل أسماء المستخدمين على الأسماء الكاملة، فإن هذا القيد يقدم احتكاكًا حقيقيًا وسلوكًا غير متوقع.
أتفهم أنه يجب موازنة الأولويات، ولكن سيكون من المفيد للغاية الحصول على تحديث من الفريق حول ما إذا كان هذا على الرادار. شكرًا مقدمًا على أي رؤى يمكنك تقديمها.
مرحبًا، @tobiaseigen، هل هناك أي مدخلات هندسية حول هذا؟ (لقد مرت 3 أشهر — ولكنني كنت مشغولاً بأشياء أخرى وفقدت تتبع هذا بنفسي، لذلك لا يمكنني الشكوى.)
يمكنني البدء في تقديم طلب سحب (طلبات سحب) هذا الأسبوع لجعل المحادثة أكثر واقعية — ولكنني أخشى أن تظل دون مراجعة، ويمكنني أيضًا الحصول على بعض الملاحظات حول بعض جوانب نهجي.
@mdoggydog يبدو أن حلك هنا هو استبدال إعداد “enable names” (تمكين الأسماء) بإعداد يأخذ قائمة بالمجموعات، ولا تكون أسماء الأعضاء مرئية إلا لتلك المجموعات.
لاحظ أن هذا سيظل بحاجة إلى احترام إعداد “display name on posts” (عرض الاسم في المنشورات) (وأي إعدادات مماثلة أخرى قد تكون موجودة)، لذلك حتى المجموعات المسموح بها لا ترى الاسم في المنشورات إذا كان هذا الإعداد معطلاً.
بالإضافة إلى ذلك، بعض الأشياء الأخرى التي نحتاج إلى إصلاحها/تغييرها هنا كتأثيرات غير مباشرة:
يجب أن تكون الأسماء مرئية دائمًا في عرض المسؤول لملف تعريف المستخدم. سيكون هذا هو الحال بغض النظر عن أي إعدادات.
يجب أن تظهر الأسماء فقط في رسائل البريد الإلكتروني إذا كان المستخدم في مجموعة مسموح بها.
يجب أن يصلح ما ورد أعلاه المشكلات الحالية، بالإضافة إلى جعل هذه الميزة أكثر مرونة وفائدة.
هل يبدو هذا وكأنك تقترحه هنا؟ إذا كان الأمر كذلك، فسيسعدنا بالتأكيد إلقاء نظرة على أي طلب سحب (PR) ترسله مع هذا التحديث مضمنًا.
الكود الذي كتبته لا يزيل إعداد enable names،[1] ولكنه يضيف إليه:
إضافة إعداد full_names_visible_to_groups (والذي يتضمن admins و moderators كقيم إلزامية).
إضافة طريقة can_see_full_names? إلى Guardian، والتي تقوم بعملية “و” بين enable_names وعضوية المجموعة في full_names_visible_to_groups.
استخدام هذه الطريقة الجديدة في جميع الأماكن المناسبة حيث يتم عرض الاسم الكامل أو إصداره من الخادم.
1 و 2 كانا سهلين. 3 أكثر تعقيدًا، وأعلم أنني واجهت بعض الصعوبات التي لم أكن متأكدًا من كيفية حلها دون الحصول على نصيحة/إرشاد. أحتاج إلى العودة ومراجعة الكود والملاحظات بعمق. (لقد مر أكثر من شهرين منذ أن انغمست في هذا الأمر. )
(إذا كنت أتذكر، فإن display name on posts وما شابهها هي إعدادات من جانب العميل، تؤثر على عرض البيانات المستلمة من الخادم. بعبارة أخرى، قيد إضافي على ما يصدره الخادم.)
أعتقد أن (1) تم التعامل معها إذا كان enable_names صحيحًا، وهو ما قد يريده الجميع تقريبًا بمجرد توفر الإعداد الجديد لكل مجموعة.[2]
أتذكر بعض الحالات الأخرى التي يتم فيها تسريب الأسماء الكاملة.[4]
على أي حال، سأقوم بمراجعة الملاحظات ومحاولة تقديم طلبات سحب (PRs) هذا الأسبوع، وسأكشف عن الأسئلة المفتوحة / النهايات المفتوحة في هذه العملية.
…لعدد من الأسباب، منها: (أ) لم أكن متأكدًا من الغرض الفعلي للإعداد (انظر سؤالي في منشور سابق أعلاه)، و (ب) تركه يوفر مسار ترقية تدريجي أكثر أمانًا. ↩︎
…إذا اتخذ المرء موقفًا مفاده أن enable_names = false يعني “هذا الموقع لا يستخدم الأسماء الكاملة بأي شكل من الأشكال”. ↩︎
على سبيل المثال، عند إرسال بريد إلكتروني للدعوة إلى عنوان ما (من الواضح أنه غير مرتبط بمستخدم، وإلا فلن يحتاجوا إلى دعوة)، هل يتضمن البريد الإلكتروني الاسم الكامل للمدعو أم لا؟ ↩︎
على سبيل المثال، oneboxer.rb، عند عمل onebox لمستخدم محلي، يكتب الاسم الكامل في محتوى المشاركة المطبوخ، مما يجعله مرئيًا للجميع، وأي شخص، إلى الأبد. ↩︎
هذا الطلب هو شرط مسبق للطلبات اللاحقة، مما يضمن تمرير مثيلات Guardian بالفعل من مُسلسل إلى آخر. التفاصيل موجودة في الطلب/رسالة الالتزام. يمكن أن يبدأ النقاش حول هذا الطلب بينما أجهز الطلب التالي.
مغامرتي المصغرة في حساب GitHub
… حسنًا، كان موجودًا هناك حتى كتبت عنوان URL في مربع التحرير هنا … وبعد ذلك تم تعليق حسابي بالكامل فجأة.
لقد قدمت طلبًا لإعادة التفعيل، وسأقوم بالتحديث عندما يكون لدي تحديث.
بعد 13 ساعة، تلقيت بريدًا إلكترونيًا يقول، بشكل أساسي، “يحدث هذا أحيانًا؛ كل شيء على ما يرام الآن.” هذا أشبه بكافكا. اختفى حسابي من الموقع - لدرجة أن المنشورات التي قمت بها في المشكلات/الطلبات منذ سنوات قد اختفت، تاركة وراءها محادثات غامضة أحادية الجانب، مع عدد قليل من الاقتباسات الشبحية كدليل وحيد على أن شخصًا آخر (أنا) كان هناك.
يبدو هذا إجراءً مبالغًا فيه بشكل مرعب، ليس فقط للحساب المعلق، ولكن أيضًا لجميع المشاريع التي تم تجريد أجزاء من تاريخها بهدوء.
أدرك أن هذا سينطوي على تنسيق تغييرات في مستودعات إضافة Discourse أيضًا، مما يعني سلسلة من طلبات السحب (PR)، بترتيب عكسي لضمان اجتياز الاختبارات دائمًا (وبالطبع، أن يكون main دائمًا وظيفيًا).
أتصور أن التسلسل سيبدو كالتالي (حيث تعني CORE “طلب سحب في discourse/discourse” وتعني PLUG “طلبات سحب في مستودعات الإضافة الرسمية”):
فرض إعادة توجيه نطاق المسلسل (لا يُتوقع أي تغيير وظيفي)
أ. CORE تنفيذ فحص نطاق المسلسل، معطل افتراضيًا
ب. PLUG إصلاحات لإعادة توجيه النطاق
ج. CORE إصلاحات لإعادة توجيه النطاق، وتمكين فحص النطاق افتراضيًا
توفير Guardians بشكل استباقي (استبدال العناصر النائبة) في الأماكن الضرورية للمرحلة 4 (لا يُتوقع أي تغيير وظيفي)
CORE إصلاحات العناصر النائبة
PLUG إصلاحات العناصر النائبة
تنفيذ Guardian#can_see_full_names? بسيط يعتمد فقط على enable_names(لا يُتوقع أي تغيير وظيفي)
CORE إضافة طريقة إلى Guardian
استخدم can_see_full_names? أينما يتم إصدار الاسم الكامل (استبدال الاستخدام المجرد لـ enable_names حسب الاقتضاء) (قد يكون هناك تغيير وظيفي)
CORE استخدم طريقة Guardian الجديدة
PLUG استخدم طريقة Guardian الجديدة
تنفيذ إعداد full_names_visible_to_groups(تغيير وظيفي)
CORE إضافة إعداد جديد إلى التكوين، والتحقق من الإعداد في طريقة Guardian
(1) و(2) يختزلان إلى التأكد من استخدام Guardians بشكل أكثر اتساقًا وموثوقية في جميع أنحاء قاعدة بيانات Discourse.
(3) و(4) يدوران حول إنشاء تجريد أكثر دقة للتحكم في متى يتم الكشف عن الأسماء الكاملة بواسطة الواجهة الخلفية (تحديد الكشف اعتمادًا على أي سياق يمثله Guardian).
(5) هو أخيرًا الجزء (التافه نسبيًا) حيث يتم التحكم في عرض الاسم الكامل عن طريق عضوية المجموعة.
أنا آسف، ولكن يجب أن أرفض هذا الطلب. هذا التغيير معقد للغاية ويصعب صيانته. الأسباب الرئيسية هي:
النطاق ليس مطلوبًا دائمًا ولا ينبغي فرضه؛
تغييره وصيانته لاحقًا في جميع الأماكن، مثل الإضافات، سيكون كمية هائلة من العمل؛
PlaceholderGuarian لا يحل المشكلة ولكنه يضيف نطاقًا وهميًا (بنية إصلاحه لاحقًا)؛
في معظم الأوقات، يجب أن يتم التسلسل في وحدة التحكم، وسيتم إضافة النطاق تلقائيًا.
عرض اسم مستخدم أو اسم كامل بناءً على المجموعة أمر صعب للغاية. بدلاً من محاولة دمجه في Discourse الأساسي، هل يمكننا البدء بإنشاء إضافة؟ إذا كان مجتمعك صغيرًا، فإليك كيف يمكن أن يعمل:
قم بتعيين SiteSetting.enable_names إلى false لاستخدام اسم المستخدم دائمًا؛
حدد نقطة نهاية تُرجع خريطة من اسم المستخدم → الاسم الكامل لمستخدمي TL3؛
[اقتباس=“kris.kotlarek, post:50, topic:291912”]
لقد انتهيت للتو من طلب سحب يحل المشكلة الأصلية. سيتمكن المسؤول دائمًا من رؤية الاسم الكامل وتعديله.
[/اقتباس]
أعتقد أنه لا يزال هناك سوء فهم/خلاف جوهري حول ما يفترض أن يفعله إعداد enable_names بالضبط، وهو ما يختزل إلى هذا السؤال:
هل المقصود بإعداد enable_names أن يعني
“عدم إظهار الأسماء الكاملة علنًا.”،
“هذا الموقع لا يستخدم الأسماء الكاملة على الإطلاق.”
أعتقد أن بعض الأشخاص في هذا الموضوع يعتقدون أنه يفعل (1)، والبعض الآخر يعتقد أنه يفعل (2). انطباعي هو الأخير، أن enable_names يقرر ما إذا كان الموقع يستخدم الأسماء الكاملة على الإطلاق أم لا.
ضع في اعتبارك، عند إيقاف تشغيل enable_names:
لا يعرض مربع حوار التسجيل حقل الاسم الكامل.
لا يرى المستخدمون حقل الاسم الكامل في صفحة تفضيلات حساباتهم الخاصة؛ لا يرى المستخدمون أبدًا اسمهم الكامل في أي مكان.
أنا لا أفهم حالة الاستخدام لموقع يكون فيه المسؤولون، والمسؤولون فقط، هم الأشخاص الوحيدون الذين يعرفون حتى أن حقل الاسم الكامل موجود في النظام. إن افتقاري للخيال يجعلني متشككًا في أن أي شخص هنا يريد ذلك بالفعل. إذا كان أي شخص يريد هذا، فيرجى تنويري!
(أعتقد أن هناك أيضًا بعض سوء الفهم حول ما يحاول مسودة طلب السحب الخاص بي تحقيقه، وكيف، ولماذا — لكنني أردت معالجة سؤال “ماذا يفعل enable_names بالفعل؟” أولاً.)
نعم، يمكنني تسمية العديد من الأمثلة. غالبًا ما تمتلك الشركة المالكة للمجتمع الحق القانوني (و/أو الحاجة) لمعرفة أسماء عملائها ولكن قوانين الخصوصية تمنعها من نشر تلك الأسماء لأطراف ثالثة. يشبه الأمر إلى حد كبير سبب كون استخدام CC في بريد إلكتروني جماعي أمرًا غير مقبول ويجب عليك استخدام BCC.
حسنًا، بدأ هذا كتقرير خطأ بسيط جدًا حيث كان يتصرف بشكل خاطئ. ثم انخرطنا جميعًا في مناقشة حول ما يفترض أن يفعله، مما تسبب أيضًا في الكثير من الارتباك والمناقشة الإضافية. وهذا جيد، ولكنه كان سيكون أفضل في موضوع Feature.
إنه #1. وصف الإعداد يقول:
عرض الاسم الكامل للمستخدم في ملفه الشخصي، وبطاقة المستخدم، ورسائل البريد الإلكتروني. تعطيل لإخفاء الاسم الكامل في كل مكان.
حقيقة أن الاسم الكامل مخفي يعني أنه موجود، ويمكن للمسؤولين رؤية الأشياء المخفية.
هناك أيضًا display_name_on_posts و full_name_requirement و display_name_on_email_from.
إذا كنت تريد #2، أعتقد أنه سيكون من المنطقي البناء على full_name_requirement وإضافة خيار “أبدًا” هناك.
(ونعم، أتفق على أن enable_names يجب أن يسمى بشكل مختلف ولكن إعادة تسمية الإعدادات ليست ممتعة أبدًا). وأتفق أيضًا على أن
هل سيؤدي هذا الإصلاح إلى استعادة الوظيفة الأصلية؟ أي يمكن للمسؤول والمستخدم رؤية اسمهما الكامل؟ يبدو أن هذا التغيير قد تسبب في الكثير من المشاكل مقارنة بالوظيفة الأصلية. حتى المشرف الكامل يجب أن يكون لديه خيار لرؤية الاسم الحقيقي عبر إعداد، حيث يمكن أن يكون هذا مرغوبًا/مطلوبًا في بعض حالات الاستخدام.
بعد أن دفع الفريق هذا التغيير، أصبحت أسماء المستخدمين الذين أدخلوا الاسم الحقيقي فارغة.
هذا الإعداد في رأيي كان يجب فصله إلى إعدادين بتعريفات واضحة. مع الميزة الأحدث لتعطيل الأسماء، يكون إعدادًا جديدًا لإيقاف تشغيل الأسماء الحقيقية.
أنا محظوظ لأن لدي مجتمعًا صغيرًا. تخيل موقعًا به آلاف الأعضاء حيث تم مسح أسمائهم الحقيقية.
)
)
