由于系统进行了“静默”更改，我们最近禁用了 download_remote_images_to_local。作为网站所有者，收到有关此事的私信会很有帮助。我不确定是否还有其他更改可以像这样通过系统进行更新。
9 个赞
我见过磁盘已满时发生这种情况。是那个原因还是其他原因？
2 个赞
它没有满，只是低于我们设定的下载远程图像的阈值。
3 个赞
我认为这个建议是合理的，但不幸的是，我们可能在很长一段时间内都没有时间来处理这个问题。
将其标记为 pr-welcome，以防社区中的任何人想对此进行调查。（当我们调整设置时，会向管理员发送私信）
6 个赞
“系统”通过将默认信任级别从我们设定的“1”更改为“0”来破坏了我们的网站。
令人惊讶的是，系统可以在没有任何批准或通知的情况下对我们的生产网站进行临时更改，我们需要防止这种情况再次发生。
有什么方法可以禁用这些自动系统更改吗？
这种情况不应该发生，许多网站的默认信任级别都是 TL1。我们需要更多信息，请就此开设一个新主题。
3 个赞
原来是由于我们在设置新服务器/应用程序时启用了引导模式（bootstrap mode）导致的。
但我的信息并非主要关于这个特定的系统更改，而是关于任何系统更改都应该经过批准，以避免出现问题。如果无法获得批准，至少应该发送一封电子邮件通知所有管理员有关更改的信息（我认为这或多或少是 OP 后来询问的内容）。
感谢你们在 Discourse 上付出的所有努力！
1 个赞
你好 @Earnie_Baird，这是一个很好的反馈。
我想到的一个建议是让引导模式（bootstrap mode）更加清晰，也许当你看到它出现在标题上并点击它时，应该非常清楚地说明发生了什么。
2 个赞
除非我不知道的更改（我认为没有），否则我强烈赞成此功能请求。
我曾多次遇到磁盘空间暂时不足的问题。
每一次，我都是偶然发现该设置被禁用了。当我达到磁盘空间阈值时，我并没有想到去查看设置更改，即使我多次遇到这种情况。
我很确定在实际使用中存在许多这种情况，管理员甚至不知道，仅仅是因为他们在一年前用完了磁盘空间。
该设置的更改记录在 /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}"
重新烘焙两个给定日期之间的所有帖子
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 让我再次想起了这个话题。我认为您还可以使用“使用数据探索器结果安排一个 PM”或“使用数据探索器结果在主题中安排一个帖子”自动化脚本和数据探索器查询，以接收有关系统对站点设置更改的通知。
类似这样
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 个赞
对于任何网站来说，当某些行为发生意外变化时，拥有一个有用的查询来进行故障排除都很有帮助。甚至可能是您或您的同事管理员更改了某些内容，并产生了意想不到的效果。
我在元（meta）上创建了一个自动化，每周运行此查询，以显示上周的所有已记录更改。我们这个厨房里有很多厨师，有时很难保持全局观。
在我看来，这里的特性请求是更全面地记录所有员工的操作。
1 个赞
我分享的查询仅限于站点设置的更改以及系统执行的操作。因此，它可以帮助您注意到系统何时更改了设置，无论是由于自动化（例如，由于磁盘已满而禁用图像下载）还是在引导模式结束时更改了设置。结合自动化插件发布的帖子或私信，这可以帮助解决 OP 中描述的情况。
但是，该查询实际上无助于查找意外的更改，例如禁用了 discobot 的欢迎消息的更改，@gassim 会希望了解这一点。在 Discourse 更新期间发生的大多数设置更改都不会被记录下来，这就是为什么它们如此难以追踪的原因。
1 个赞
我已经修改了你的查询，以显示我上周记录的所有更改。
我同意你的观点，需要填补一个空白。记录的操作不够。
1 个赞