Недавно наша настройка download_remote_images_to_local была отключена системой как «тихое» изменение. Как владельцу сайта, мне было бы полезно получить об этом сообщение в личных сообщениях. Однако я не уверен, что система может обновлять и другие настройки подобным образом.
10 лайков
Я видел, как такое случается, когда диск заполнен. Это было из-за этого или что-то другое?
3 лайка
Оно не было полным, просто значение упало ниже порога, который мы установили для загрузки удалённых изображений.
4 лайка
Я считаю, что предложение разумное, но, к сожалению, думаю, что у нас не будет возможности заняться этим в ближайшее время.
Помечаю тегом pr-welcome на случай, если кто-то из сообщества захочет разобраться с этим. (Сообщайте администраторам в личные сообщения, когда будете экспериментировать с настройкой).
7 лайков
Система сломала наш сайт, изменив уровень доверия по умолчанию на «0», хотя мы установили его на «1».
Очень удивительно, что система может вносить разовые изменения в наш рабочий сайт без какого-либо согласования или уведомления, и нам необходимо предотвратить повторение этого в будущем.
Есть ли способ отключить эти автоматические изменения системы?
1 лайк
Так не должно происходить, у множества сайтов уровень доверия по умолчанию равен TL1. Нам нужен дополнительный контекст: пожалуйста, создайте новую тему по этому вопросу.
4 лайка
Итак, оказывается, это произошло из-за режима загрузки на новом сервере/приложении, которое мы настраивали.
Но мой комментарий был направлен не столько на это конкретное изменение системы, сколько на то, что любое изменение системы в идеале должно требовать утверждения, чтобы ничего не сломалось. Если утверждение невозможно, то как минимум стоит отправить всем администраторам уведомление об изменении по электронной почте (что, как мне кажется, было тем, о чём спрашивал автор оригинального сообщения). Это было бы отлично.
Спасибо за всю вашу работу над Discourse!
2 лайка
Привет, @Earnie_Baird, это отличный фидбек.
Предложение: сделать режим загрузки (bootstrap mode) более понятным. Например, когда вы видите его в заголовке и нажимаете на него, должно быть четко объяснено, что произошло.
3 лайка
Если не было изменений, о которых я не знал (а я не думаю, что они были), я решительно поддерживаю эту просьбу о добавлении функции.
Я сталкивался с этой проблемой несколько раз, когда временно не хватало места на диске.
Каждый раз я замечал, что настройка была отключена, только случайно. Я не думал проверять изменения настроек при достижении порога свободного места на диске, даже после того, как это случалось со мной несколько раз.
Я почти уверен, что в реальной жизни есть множество случаев, когда эта настройка отключена, даже без ведома администратора, просто потому что место на диске закончилось ещё год назад.
Изменение этой настройки записывается в /admin/logs/staff_action_logs?filters=%7B"subject"%3A"download_remote_images_to_local"%7D, но я не помню, чтобы получал какие-либо уведомления при её срабатывании.
В идеале я бы хотел получить хотя бы предупреждение в панели управления, уведомление в меню пользователя или письмо по электронной почте.
Контекст следующей цитаты был довольно специфичным (и старым), но он также применим и здесь.
Отсутствие каких-либо уведомлений при изменении настройки системой (@system) может быть вредным.
Когда я замечаю, что download_remote_images_to_local был отключен в какой-то момент, я запускаю один из (или оба, по разу) этих скриптов на Ruby on Rails, чтобы инициировать загрузку удалённых файлов:
Пересобрать все сообщения с указанной даты
i = 0
Post.where('created_at >= ?', Date.new(2023, 5, 1)).where('user_id > 0').find_each do |post|
post.rebake!
puts "Сообщение #{post.id}, создано #{post.created_at}"
i += 1
end
puts "Общее количество пересобранных сообщений: #{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.id}, создано #{post.created_at}"
i += 1
end
puts "Общее количество пересобранных сообщений: #{i}"
3 лайка
Чтение статьи Get admin notification from logs? - #4 by JammyDodger снова навело меня на эту тему. Я думаю, что также можно использовать автоматизацию «Запланировать личное сообщение с результатами Data Explorer» или «Запланировать пост в теме с результатами 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
Затем настройте автоматизацию с периодичностью, соответствующей интервалу в запросе, и исключите случаи, если результатов нет, чтобы избежать лишнего шума.
Вы также можете улучшить запрос, отфильтровав конкретную тему, но, возможно, другие автоматические изменения тоже представляют интерес.
5 лайков
Привет, @Moin!
Спасибо за это, идея звучит очень полезной!
Я выполнил этот запрос, но он не показывает такие изменения, как автоматическое отключение Narrative.
1 лайк
Верно! В логах нет записи об этом. Автоматизация уведомляет вас только об изменениях, зафиксированных в логах действий персонала. Именно поэтому я предложил всегда создавать запись для таких изменений.
Этот запрос намеренно ограничивает временной интервал. Когда я закомментирую ограничение по времени, я вижу хотя бы некоторые изменения, но для большинства из них нет записей в логе.
- AND uh.updated_at > CURRENT_TIMESTAMP - INTERVAL '60 minutes'
+ --AND uh.updated_at > CURRENT_TIMESTAMP - INTERVAL '60 minutes'
Однако, чтобы предотвратить сообщение автоматизированным скриптом об этих старых изменениях, я добавил это ограничение по времени.
3 лайка
Это полезный запрос для любого сайта при устранении неполадок, когда какое-то поведение изменилось неожиданно. Возможно, это сделали вы или другой администратор, и это привело к непредвиденным последствиям.
Я создал автоматизацию на Meta, которая выполняет этот запрос еженедельно, чтобы показать все зарегистрированные изменения за последнюю неделю. У нас в этой кухне много поваров, и иногда бывает трудно поддерживать общий обзор.
Мне кажется, что в данном случае запрос на новую функцию заключается в более полном регистрации всех действий сотрудников.
2 лайка
Представленный мной запрос ограничен изменениями настроек сайта и действиями системы. Он помогает отслеживать, когда настройки меняются системой — например, из-за автоматизации (как отключение загрузки изображений при заполненном диске) или когда заканчивается режим начальной загрузки. В сочетании с сообщением или личным письмом от плагина автоматизации это может помочь в случаях, подобных описанному в исходном сообщении.
Однако этот запрос не очень помогает найти неожиданные изменения, такие как отключение приветственного сообщения от discobot, о котором, вероятно, хотел бы узнать @gassim. Большинство изменений настроек, происходящих во время обновления Discourse, не регистрируются, и именно это делает их такими сложными для отслеживания.
2 лайка
Я изменил ваш запрос, чтобы показать все зафиксированные изменения за последнюю неделю.
Я согласен с вами, что необходимо восполнить пробел. Записывается недостаточно действий.
2 лайка
Две мысли на этот счёт:
- Это может быть легко реализовано как проверка проблем, которая добавит уведомление администратора на панель управления.
- Код знает, когда заканчивается место на диске, и отключает настройку. Но код также знает, когда места на диске достаточно, и теоретически должен иметь возможность возобновить загрузку. Однако для этого потребовался бы другой источник истины, поскольку код не знает, что настройка должна быть включена.