システムによって download_remote_images_to_local が「サイレント」な変更として無効化されました。サイトオーナーとしては、これについてDMで通知を受け取ることができれば便利でした。システムによってこのように更新できる変更が他にもあるのかどうかはわかりません。
「いいね！」 9
ディスクがいっぱいになっている場合に発生することがありますが、それ以外に原因はありましたか？
「いいね！」 2
しきい値を下回っただけで、リモート画像のダウンロードには十分でした。
「いいね！」 3
提案は妥当だと思いますが、残念ながらしばらくの間この件に取り組む時間はないと思います。
コミュニティの誰かが調査したい場合に備えて、この件に#pr-welcomeを付けます。（設定を変更する際に管理者にPMします）
「いいね！」 6
「システム」がデフォルトの信頼レベルを「1」に設定していたものを「0」に変更したことで、私たちのサイトが壊れてしまいました。
システムが承認や通知なしに本番サイトに随時変更を加えることができるのは非常に驚くべきことであり、今後このようなことが二度と起こらないようにする必要があります。
これらの自動システム変更を無効にする方法はありますか？
これは起こるべきではありません。多くのサイトではデフォルトでTL1が設定されています。より詳しい情報が必要です。この件について新しいトピックを作成していただけますか。
「いいね！」 3
というわけで、これは設定中の新しいサーバー/アプリのブートストラップモードが原因で発生したことが判明しました。
しかし、私のメッセージは、この特定のシステム変更についてというよりも、システム変更は理想的には承認が必要であり、そうしないと問題が発生するということについてでした。承認が不可能な場合は、少なくともすべての管理者に変更を通知するメール（これはOPが求めていたこととほぼ同じだと思います）があれば素晴らしいでしょう。
Discourseのすべての作業に感謝します！
「いいね！」 1
Earnie_Baird様、素晴らしいフィードバックをありがとうございます。
ブートストラップモードについて、もう少し明確にすると良いかもしれません。ヘッダーに表示されてそれをクリックした際に、何が起こったのかが非常に明確にわかるようにすると良いでしょう。
「いいね！」 2
変更が認識されていない限り（そしてそうは思えませんが）、この機能リクエストを強く承認します。
ディスク容量が一時的に不足した場合に、この問題に数回遭遇しました。
毎回、設定が無効になっていることに偶然気づきました。ディスク容量のしきい値に達しても、この問題を何度も経験した後でさえ、設定の変更を確認しようとは思いませんでした。
1年前にディスク容量不足になっただけで、この設定が無効になっていることに管理者が気づいていないケースが多数あると確信しています。
設定の変更は /admin/logs/staff_action_logs?filters=%7B\"subject\"%3A\"download_remote_images_to_local\"%7D で記録されますが、トリガーされたときに通知を受け取った記憶はありません。
理想的には、ダッシュボードでの警告、ユーザーメニューでの通知、またはメールのいずれかが必要です。
以下の引用の文脈は非常に具体的（そして古い）でしたが、ここでも同様に適用できます。
@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}"
2つの指定した日付間のすべての投稿をリベイクする
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}"
「いいね！」 2
Get admin notification from logs? - #4 by JammyDodger を読んで、このトピックのことを思い出しました。Data Explorer の結果を使用して「PM をスケジュールする」または「Data Explorer の結果をトピックに投稿する」自動化スクリプトと Data Explorer クエリを使用して、システムによるサイト設定の変更に関する通知を受け取ることもできると思います。
例えば、
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
その後、クエリの間隔に一致する繰り返しで自動化を設定し、結果がない場合はノイズを避けるためにスキップします。
クエリを改善して正確な件名でフィルタリングすることもできますが、他の自動変更も興味深いかもしれないと思いました。
「いいね！」 3
その通りです！ログにこのエントリはありません。そのため、このような変更は常にエントリを作成すべきだと提案しました。
このクエリは意図的に短い期間のみをクエリします。時間制限をコメントアウトすると、少なくともいくつかの変更が見られます。
- AND uh.updated_at > CURRENT_TIMESTAMP - INTERVAL '60 minutes'
+ --AND uh.updated_at > CURRENT_TIMESTAMP - INTERVAL '60 minutes'
ただし、自動化スクリプトがこれらの古い変更を報告しないようにするために、この時間制限を追加しました。
「いいね！」 2
これは、予期せず動作が変更された場合に、トラブルシューティングを行う上で、どのサイトにとっても役立つクエリです。あなた自身や同僚の管理者が何かを変更し、それが予期せぬ影響を及ぼした可能性もあります。
私はここでメタに自動化を作成し、毎週このクエリを実行して、過去1週間のすべてのログ変更を表示するようにしました。このキッチンには多くの料理人がおり、全体像を把握するのが難しい場合があります。
ここでの機能リクエストは、すべてのスタッフのアクションをより包括的にログに記録することだと思われます。
「いいね！」 1
私が共有したクエリは、サイト設定の変更とシステムによるアクションに限定されています。そのため、自動化によって設定が変更された場合（たとえば、ディスクがいっぱいになったために画像のダウンロードが無効になった場合や、ブートストラップモードが終了したときに設定が変更された場合など）に気づくのに役立ちます。自動化プラグインによる投稿やプライベートメッセージと組み合わせることで、OPで説明されているようなケースに役立ちます。
しかし、このクエリは、discobotのウェルカムメッセージを無効にしたような予期しない変更を見つけるのにはあまり役立ちません。@gassimは、それについて知りたかったでしょう。Discourseのアップデート中に発生するほとんどの設定変更はログに記録されないため、追跡が困難になります。
「いいね！」 1
過去1週間に記録されたすべての変更を表示するようにクエリを変更しました。
ログに記録されるアクションが不足しているという点については、同意します。
「いいね！」 1