Nous avons récemment désactivé notre download_remote_images_to_local par le système comme un changement « silencieux ». En tant que propriétaire du site, il aurait été utile de recevoir un message privé à ce sujet. Je ne suis pas sûr s’il existe d’autres changements qui peuvent être mis à jour par le système de cette façon cependant.
9 « J'aime »
J’ai vu que cela se produisait lorsque le disque était plein. Était-ce cela ou autre chose ?
2 « J'aime »
Il n’était pas plein, il passait juste sous le seuil que nous avions défini pour le téléchargement d’images distantes.
3 « J'aime »
Je pense que la suggestion est raisonnable, malheureusement je ne pense pas que nous aurons le temps de travailler dessus avant un bon moment.
Nous y ajoutons un pr-welcome au cas où quelqu’un de la communauté voudrait l’examiner. (Un message privé aux administrateurs lorsque nous modifierons le paramètre)
6 « J'aime »
Le « système » a planté notre site en modifiant le niveau de confiance par défaut à « 0 » alors que nous l’avions défini sur « 1 ».
Il est très surprenant que le système puisse apporter des modifications ad hoc à notre site de production sans aucune approbation ni notification, et nous devons empêcher que cela ne se reproduise à l’avenir.
Existe-t-il un moyen de désactiver ces modifications automatiques du système ?
Cela ne devrait pas arriver, de nombreux sites ont un niveau de confiance par défaut de TL1. Nous avons besoin de plus de contexte, pouvez-vous ouvrir un nouveau sujet à ce sujet.
3 « J'aime »
Il s’avère que cela s’est produit en raison du mode bootstrap sur un nouveau serveur/application que nous mettions en place.
Mais mon message portait moins sur ce changement de système spécifique et davantage sur la manière dont tout changement de système devrait idéalement nécessiter une approbation afin que les choses ne se cassent pas. Si l’approbation n’est pas possible, alors au minimum un e-mail informant tous les administrateurs du changement (ce qui, je pense, est plus ou moins ce que l’OP demandait) serait formidable.
Merci pour tout le travail sur Discourse !
1 « J'aime »
Salut @Earnie_Baird, ce sont d’excellents commentaires.
Je suppose qu’une suggestion serait d’avoir plus de clarté sur le mode bootstrap, peut-être lorsque vous le voyez dans l’en-tête et que vous cliquez dessus, cela devrait expliquer très clairement ce qui s’est passé.
2 « J'aime »
Sauf s’il y a eu des changements dont je ne suis pas au courant (et je ne pense pas qu’il y en ait eu), j’approuve fortement cette demande de fonctionnalité.
J’ai rencontré ce problème plusieurs fois lorsque je manquais temporairement d’espace disque.
À chaque fois, j’ai remarqué que le paramètre était désactivé par hasard. Je n’ai pas pensé à vérifier les changements de paramètres lorsque j’atteignais un seuil d’espace disque, même après l’avoir vécu plusieurs fois.
Je suis à peu près sûr qu’il existe de nombreuses instances en production où ce paramètre est désactivé sans que l’administrateur ne le sache, simplement parce qu’ils ont manqué d’espace disque il y a un an.
Le changement de paramètre est consigné dans /admin/logs/staff_action_logs?filters=%7B\"subject\"%3A\"download_remote_images_to_local\"%7D, mais je ne me souviens pas avoir reçu de notification lorsque cela se déclenche.
Idéalement, j’aimerais au moins un avertissement dans le tableau de bord, une notification dans le menu utilisateur ou un e-mail.
Le contexte de la citation suivante était assez spécifique (et ancien), mais il s’applique également ici.
L’absence de toute notification lorsqu’un paramètre est modifié par @system peut être préjudiciable.
Lorsque je remarque que download_remote_images_to_local a été désactivé à un moment donné, j’exécute l’un (ou les deux, une fois) de ces scripts Rails pour déclencher le téléchargement des fichiers distants :
Re-cuire tous les messages à partir d’une date donnée
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}"
Re-cuire tous les messages entre deux dates données
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 « J'aime »
La lecture de Get admin notification from logs? - #4 by JammyDodger m’a fait repenser à ce sujet. Je pense que vous pourriez également utiliser le script d’automatisation « Planifier un message privé avec les résultats de Data Explorer » ou « Planifier un message dans un sujet avec les résultats de Data Explorer » et une requête Data Explorer pour recevoir des notifications sur les modifications des paramètres du site par le système.
Quelque chose comme
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
Ensuite, vous configurez l’automatisation avec une récurrence correspondant à l’intervalle dans la requête, et vous sautez s’il n’y a pas de résultats pour éviter le bruit.
Vous pourriez également améliorer la requête pour filtrer le sujet exact, mais j’ai pensé que d’autres modifications automatiques pourraient également être intéressantes.
3 « J'aime »
Salut @Moin
Merci, cela semble être une idée très utile !
J’ai exécuté cette requête mais elle n’affiche pas les changements tels que la désactivation automatique du Narrative..
C’est exact ! Il n’y a aucune entrée dans les journaux pour cela. C’est pourquoi j’ai suggéré qu’une entrée soit toujours créée pour de tels changements.
Cette requête ne recherche délibérément qu’une courte période. Lorsque je commente la restriction de temps, je vois au moins quelques changements.
- AND uh.updated_at > CURRENT_TIMESTAMP - INTERVAL '60 minutes'
+ --AND uh.updated_at > CURRENT_TIMESTAMP - INTERVAL '60 minutes'
Cependant, pour empêcher le script d’automatisation de signaler ces anciens changements, j’ai ajouté cette restriction de temps.
2 « J'aime »
C’est une requête utile pour n’importe quel site afin de dépanner lorsqu’un comportement a changé de manière inattendue. Il se peut même que ce soit vous ou un autre administrateur qui a changé quelque chose et cela a eu un effet inattendu.
J’ai créé une automatisation ici sur meta pour exécuter cette requête chaque semaine, afin de montrer toutes les modifications enregistrées la semaine dernière. Nous avons beaucoup de monde dans cette cuisine et il peut être difficile de garder une vue d’ensemble.
Il me semble que la demande de fonctionnalité ici serait d’enregistrer toutes les actions du personnel de manière plus complète.
1 « J'aime »
La requête que j’ai partagée est limitée aux changements dans les paramètres du site et aux actions du système. Elle aide donc à remarquer lorsque les paramètres sont modifiés par le système, soit en raison d’une automatisation, comme la désactivation du téléchargement d’images parce que le disque est plein, soit lorsque le paramètre change à la fin du mode bootstrap. En combinaison avec un post ou un MP de plugin d’automatisation, cela peut aider dans les cas décrits dans l’OP.
Mais la requête n’aide pas vraiment à trouver des changements inattendus comme celui qui a désactivé le message de bienvenue de discobot, que @gassim aurait aimé connaître. La plupart des changements de paramètres qui se produisent lors d’une mise à jour de Discourse ne sont pas enregistrés, ce qui rend leur suivi si difficile.
1 « J'aime »
J’ai modifié votre requête pour qu’elle affiche toutes les modifications enregistrées la semaine dernière.
Je suis d’accord avec vous sur le fait qu’il y a une lacune à combler. Pas assez d’actions sont enregistrées.
1 « J'aime »