يبدو من الواجهة أن النظام لن يرسل بريدًا إلكترونيًا للمستخدم عند تعليقه، ما لم تقم بتعبئة القسم السفلي هنا — حيث يذكر فقط أنه سيظهر لهم نص معين عند محاولة تسجيل الدخول:
لكن عندما كنت أجرب شيئًا بحساب تجريبي، لاحظت أنه أرسل بالفعل بريدًا إلكترونيًا يخطر المستخدم بالتعليق. كما أرسل بريدًا إلكترونيًا أيضًا عندما كتمت صوت المستخدم التجريبي. يتم إرسال هذه الرسائل فورًا، لذا لا يوجد حتى وقت للدخول إلى sidekiq لإيقافها.
سبب عدم رغبتي في إرسال رسائل بريدية لهؤلاء الأشخاص هو أنني لا أريد تذكيرهم بوجود الموقع. (جميع عمليات التعليق دائمة ما لم يرغبوا في الاستئناف عبر البريد الإلكتروني.)
تعديل: بعد نشر هذا الموضوع، رأيت أنني استلمت بريدًا إلكترونيًا آخر عندما ألغيت تعليق الحساب التجريبي. لا أعتقد أنه ينبغي إرسال بريد إلكتروني لهذا الغرض أيضًا، ما لم يقوم المدير بوضع علامة على مربع اختيار، لأن المستخدم قد لا يعلم أنه تم تعليقه أو كتم صوته بواسطة النظام.
هل من الممكن تغيير الأمر بحيث لا يتم إرسال رسائل البريد الإلكتروني افتراضيًا، مع إضافة مربع اختيار يقول «أرسل للمستخدم رسالة بريد إلكتروني»؟ حاليًا، تقول الواجهة التفاعلية والتوثيق في المنتدى أن عمليات التعليق والصمت لن ترسل رسائل بريد إلكتروني إلا إذا تمت تعبئة منطقة النص السفلية.
إذا تم إرسال رسائل البريد الإلكتروني تلقائيًا، فلن أتمكن من استخدام الواجهة التفاعلية لتعليق أو كتم المستخدمين، وسيتعين علي تسجيل الدخول عبر ssh للقيام بذلك في وحدة تحكم Rails أو إيجاد طريقة أخرى للقيام بذلك دون إرسال رسائل بريد إلكتروني.
لن أرسل أبدًا رسائل بريد إلكتروني لهذا النوع من قرارات الإشراف، لأن ذلك سيذكّر المستخدمين غير المرغوب فيهم بوجود المنتدى، وكل ما أريده هو اختفاؤهم. إذا عادوا إلى المنتدى، فسيرون سبب الإشراف، لكن معظمهم لن يعودوا.
ليس لدينا تعليق أو صمت مؤقت — فهو دائمًا دائم. أمنح المستخدمين عدة تحذيرات ليصلحوا أنفسهم، ولكن إذا لم يتمكنوا من ذلك، فإنهم يُعلَّقون ويمكنهم الاستئناف عبر البريد الإلكتروني.
قال وكيل برمجة إنه يمكنه كتابة إضافة لكبت تلك الرسائل، ولكن لا يوجد خطاف رسمي لحجب تلك الرسائل. قد يؤدي تحديث للنواة في المستقبل إلى كسر الإضافة.
إذا كانت الأسباب وراء عدم الرغبة في إرسال تلك الرسائل غير مفهومة، فيمكنني نشر سيناريوهات مثالية.
نعم، الأمر ممكن. نحن نعمل على تمكين استخدام Discourse بطريقة تتوافق مع شكاوى قانون الخدمات الرقمية (DSA)، لذلك ستتاح لنا تحديثات أكثر، والملاحظات تساعدنا في ذلك.
ومع ذلك، تجدر الإشارة إلى أنه إذا كان منتداك يعمل من الاتحاد الأوروبي أو لديه مستخدمون فيه، فإن قانون الخدمات الرقمية (المادة 17) يلزمك بتقديم بيان للأسباب للمستخدمين الذين تم تعليق حساباتهم أو كتم أصواتهم.
وبما أنه من الصعب معرفة موقع كل مستخدم، فأنصح بالاحتفاظ بالبريد الإلكتروني كخيار افتراضي وتخطيه فقط لحسابات البريد المزعج/الروبوتات، والتي يعفيها القانون من هذا الشرط.
لا أرى في المادة 17 أي متطلبات تنص على إرسال أسباب الإشراف عبر البريد الإلكتروني. إذا كان بإمكان المستخدم رؤية هذه الأسباب المنشورة على الموقع عند محاولة تسجيل الدخول أثناء التعليق، أو إذا ما زال بإمكانه تسجيل الدخول أثناء الكتم، ألا يكون ذلك كافيًا لتلبية المتطلب؟
شكراً على التوضيح. لم أسمع من قبل بقانون الخدمات الرقمية.
أنا مرتبك بشأن القانون. Gmail هو موقع إلكتروني؛ منتدائي هو أيضاً موقع إلكتروني. لماذا يُعتبر زيارة gmail.com لعرض الرسائل “إشعاراً” بينما لا يُعتبر زيارة نظام الرسائل على موقعي لعرض الإشعارات “إشعاراً”؟ يبدو أن هذا سيعطي تفضيلاً غير عادل لشركات التكنولوجيا الكبرى. إذا أجبتهم بالذهاب إلى Google للإشعار بالإضافة إلى إشعارهم على موقعي عبر نظام الرسائل الخاص بي، سأكون قد أعطيتهم إشعاراً مزدوجاً.
أعرض دائماً سبباً، لذلك سيرى المستخدمون ذلك عندما يأتون للتحقق من الرسائل التي تلقوها على المنتدى. يمكن للناس دائماً استئناف قرارات الإشراف عن طريق إرسال بريد إلكتروني إلينا. أشخاص حقيقيون يجيبون على رسائل البريد الإلكتروني، ورابط الاتصال متاح في القائمة المنسدلة.
أفضل أن أترك هذه رسائل البريد الإلكتروني معطلة بشكل افتراضي حتى يتم توضيح القانون. لا أريد أن يتلقى أي شخص رسائل بريد إلكتروني عند تعليقه يدوياً، أو كتم صوته، أو رفع التعليق عنه، أو إلغاء الكتم عنه، ما لم أملأ حقل نص البريد الإلكتروني.
إذا لم تتمكنوا من تعديل Discourse لتعطيل تلك رسائل البريد الإلكتروني بشكل افتراضي، فهل يمكنكم إنشاء واجهة برمجة تطبيقات (API) مستقرة يمكن لملحق (plugin) أن يتفاعل معها لمنع إشعارات معينة؟ (إذا لم تكن موجودة بالفعل — لم يستطع Claude العثور على واحدة)
أي نوع من الخطافات (hooks) لذلك سيكون مفيداً أيضاً لي، بحيث أستطيع كتابة ملحق يمنع إرسال رسائل البريد الإلكتروني عند موافقة الإشراف على منشور. لا أريد أبداً إرسال تلك الرسائل أيضاً، لذا يجب علي دائماً الدخول إلى Sidekiq لإلغاء تلك المهام يدوياً. وإلا فإن البريد الإلكتروني يذكر المستخدم بأنه استغرق ساعات للموافقة على منشوراته، وفي غضون ذلك قد يكون يشعر بالسوء بسبب ذلك. كنت سأجعل Claude يكتب ملحقاً، لكنه قال أنه سيعدل الوظائف الأساسية، وقد ينكسر الملحق عند التحديث، مما يعني أنني ربما ما زلت مضطراً للتحقق من Sidekiq كل مرة أوافق فيها على منشور للتأكد من عدم طابور مهام البريد الإلكتروني.
فقط إذا كانت الأسباب تتعلق بمحتوى غير قانوني أو بالعمل ضد الشروط والأحكام. لكن ليس إذا كان السبب هو الرسائل المزعجة (سبام). أو إذا كان السبب هو طلب رسمي (حكومي).
لذلك، دعونا لا نمنح هذا النوع من القوانين نطاقًا أوسع مما هو موجود بالفعل. يجب ألا يشمل كتم الأصوات أو التعليق بسبب السلوك الاجتماعي العدائي أو الرسائل المزعجة.
(هذا حجة لصالح ترتيب الأمور بحيث لا تمنع الشروط والأحكام السلوك الاجتماعي العدائي)
