تم تعطيل download_remote_images_to_local مؤخرًا بواسطة النظام كتغيير “صامت”. بصفتي مالك موقع، كان من المفيد تلقي رسالة خاصة حول هذا الأمر. لست متأكدًا مما إذا كانت هناك تغييرات أخرى يمكن تحديثها بواسطة النظام بهذه الطريقة على الرغم من ذلك.
لقد رأيت ذلك يحدث عندما يكون القرص ممتلئًا. هل كان ذلك أم شيء آخر؟
لم يكن ممتلئًا، بل كان ينخفض عن الحد الذي حددناه لتنزيل الصور عن بُعد.
أعتقد أن الاقتراح معقول، للأسف لا أعتقد أن لدينا وقتًا للعمل على هذا لفترة طويلة.
وضع علامة pr-welcome عليه في حال أراد أي شخص في المجتمع التحقيق في هذا. (رسالة خاصة للمسؤولين عند العبث بالإعداد)
تعطل “النظام” موقعنا عن طريق تغيير مستوى الثقة الافتراضي إلى “0” عندما كنا قد ضبطناه على “1”.
من المدهش جدًا أن النظام يمكنه إجراء تغييرات مخصصة على موقع الإنتاج الخاص بنا دون أي نوع من الموافقات أو الإشعارات، ونحن بحاجة إلى منع حدوث ذلك مرة أخرى في المستقبل.
هل هناك أي طريقة لتعطيل هذه التغييرات التلقائية للنظام؟
لا ينبغي أن يحدث هذا، فالعديد من المواقع لديها مستوى ثقة افتراضي TL1. نحتاج إلى مزيد من السياق، هل يمكنك فتح موضوع جديد حول هذا الأمر.
اتضح أن هذا حدث بسبب وضع التمهيد (bootstrap mode) على خادم/تطبيق جديد كنا نقوم بإعداده.
لكن رسالتي كانت أقل حول تغيير النظام المحدد هذا وأكثر حول كيف يجب أن يتطلب أي تغيير في النظام موافقة مثالية حتى لا تتعطل الأمور. إذا لم تكن الموافقة ممكنة، فعلى الأقل، سيكون البريد الإلكتروني الذي يخطر جميع المسؤولين بالتغيير (وهو ما أعتقد أن السائل كان يسأل عنه تقريبًا) رائعًا.
شكرًا على كل العمل الذي تم في Discourse!
مرحباً @Earnie_Baird، هذه ملاحظات رائعة.
أعتقد أن أحد الاقتراحات هو توضيح وضع التمهيد (bootstrap mode) بشكل أكبر، ربما عندما تراه في الرأس وتنقر عليه، يجب أن يوضح بوضوح ما حدث.
ما لم تكن هناك تغييرات لم أكن على علم بها (ولا أعتقد أن هناك)، فإنني أوافق بشدة على طلب الميزة هذا.
لقد واجهت هذه المشكلة عدة مرات عندما كنت أفتقر مؤقتًا إلى مساحة القرص.
في كل مرة، لاحظت أن الإعداد كان معطلاً بالصدفة. لم أفكر في النظر إلى تغييرات الإعدادات عندما أصل إلى حد مساحة القرص، حتى بعد تجربته عدة مرات.
أنا متأكد من أن هناك العديد من الحالات في الواقع التي يكون فيها هذا الإعداد معطلاً دون علم المسؤول، فقط لأنهم نفدوا من مساحة القرص قبل عام.
يتم تسجيل تغيير الإعداد في /admin/logs/staff_action_logs?filters=%7B\"subject\"%3A\"download_remote_images_to_local\"%7D، لكنني لا أتذكر أنني تلقيت أي إشعار عند تشغيله.
من الناحية المثالية، أود إما تحذيرًا على الأقل في لوحة التحكم، أو إشعارًا في قائمة المستخدم، أو بريدًا إلكترونيًا.
كان سياق الاقتباس التالي محددًا جدًا (وقديماً)، ولكنه ينطبق هنا أيضًا.
[quote=“Arkshine, post:7, topic:139142”]
إذا كانت قيمة إعداد معين بحاجة إلى تغيير، فسأرغب في توقع أن يخبر Discourse المسؤول بما يحدث. الأمر يتعلق فقط بالشفافية وجعل حياة المسؤول أقل إيلامًا.
عدم وجود أي نوع من الإشعارات عند تغيير إعداد بواسطة @system يمكن أن يكون ضارًا.
عندما ألاحظ أن download_remote_images_to_local قد تم تعطيله في مرحلة ما، أقوم بتشغيل أحد (أو كليهما، مرة واحدة) هذه البرامج النصية لـ rails لتشغيل تنزيل الملفات البعيدة:
إعادة خبز جميع المشاركات من تاريخ معين
i = 0
Post.where('created_at >= ?', Date.new(2023, 5, 1)).where('user_id > 0').find_each do |post|
post.rebake!
puts "Post #{post.id}, Created at #{post.created_at}"
i += 1
end
puts "Total number of posts rebaked: #{i}"
إعادة خبز جميع المشاركات بين تاريخين محددين
i = 0
Post.where('created_at >= ? AND created_at < ?', Date.new(2021, 12, 1), Date.new(2022, 3, 1)).where('user_id > 0').find_each do |post|
post.rebake!
puts "Post #{post.id}, Created at #{post.created_at}"
i += 1
end
puts "Total number of posts rebaked: #{i}"
قراءة Get admin notification from logs? - #4 by JammyDodger جعلتني أفكر في هذا الموضوع مرة أخرى. أعتقد أنه يمكنك أيضًا استخدام البرنامج النصي الآلي “جدولة رسالة خاصة مع نتائج مستكشف البيانات” أو “جدولة منشور في موضوع مع نتائج مستكشف البيانات” واستعلام مستكشف البيانات لتلقي إشعارات بالتغييرات في إعدادات الموقع بواسطة النظام.
شيء مثل
SELECT subject, previous_value, new_value, updated_at
FROM user_histories uh
where uh.action = 3
AND uh.acting_user_id = -1
AND uh.updated_at > CURRENT_TIMESTAMP - INTERVAL '60 minutes'
order by updated_at desc
ثم تقوم بإعداد الأتمتة بتكرار يطابق الفترة الزمنية في الاستعلام، وتخطي إذا لم تكن هناك نتائج لتجنب الضوضاء.
يمكنك أيضًا تحسين الاستعلام للتصفية حسب الموضوع المحدد، ولكنني اعتقدت أنه ربما تكون التغييرات التلقائية الأخرى مثيرة للاهتمام أيضًا.
مرحباً @Moin
شكراً لك، تبدو فكرة مفيدة جداً!
لقد قمت بتشغيل هذا الاستعلام ولكنه لا يُظهر تغييرات مثل تعطيل السرد التلقائي..
صحيح! لا يوجد سجل في السجلات لهذا. لهذا السبب اقترحت أنه يجب دائمًا إنشاء سجل لمثل هذه التغييرات.
هذا الاستعلام يستعلم عن فترة زمنية قصيرة فقط عن قصد. عندما أقوم بالتعليق على قيد الوقت، أرى تغييرات قليلة على الأقل.
- AND uh.updated_at > CURRENT_TIMESTAMP - INTERVAL '60 minutes'
+ --AND uh.updated_at > CURRENT_TIMESTAMP - INTERVAL '60 minutes'
ومع ذلك، لمنع نص الأتمتة البرمجي من الإبلاغ عن تلك التغييرات القديمة، أضفت قيد الوقت هذا.
هذا استعلام مفيد لأي موقع لاستخدامه في استكشاف الأخطاء وإصلاحها، عندما يتغير سلوك ما بشكل غير متوقع. قد تكون أنت أو زميل لك في الإدارة قد غيرت شيئًا وكان له تأثير غير متوقع.
لقد أنشأت أتمتة هنا في ميتا لتشغيل هذا الاستعلام أسبوعيًا، لعرض جميع التغييرات المسجلة في الأسبوع الماضي. لدينا الكثير من الطهاة في هذا المطبخ وقد يكون من الصعب أحيانًا الحفاظ على نظرة عامة.
يبدو لي أن طلب الميزة هنا هو تسجيل جميع إجراءات الموظفين بشكل أكثر شمولاً.
الاستعلام الذي شاركته يقتصر على التغييرات في إعدادات الموقع ويقتصر على الإجراءات التي يقوم بها النظام. لذا فهو يساعد في ملاحظة متى يتم تغيير الإعدادات بواسطة النظام إما بسبب التشغيل الآلي، مثل تعطيل تنزيل الصور بسبب امتلاء القرص أو تغيير الإعداد عند انتهاء وضع التمهيد. بالاشتراك مع منشور أو رسالة خاصة من المكون الإضافي للتشغيل الآلي، يمكن أن يساعد ذلك في الحالات الموصوفة في الموضوع الأصلي.
لكن الاستعلام لا يساعد حقًا في العثور على التغييرات غير المتوقعة مثل التغيير الذي عطّل رسالة الترحيب الخاصة بـ discobot، والتي كان سيود @gassim معرفتها. معظم تغييرات الإعدادات التي تحدث أثناء تحديث Discourse لا يتم تسجيلها، وهذا ما يجعل تتبعها صعبًا للغاية.
لقد عدلت استعلامك لعرض جميع التغييرات المسجلة في الأسبوع الماضي.
أتفق معك في أن هناك فجوة تحتاج إلى سد. لا يتم تسجيل إجراءات كافية.
