Laissez-moi revenir en arrière… ce que je faisais, c’était d’essayer de modifier les préférences d’administration dans l’espoir que le code qui lève l’exception n’aurait pas besoin d’être exécuté.
Mais ce que nous voulons vraiment, c’est vérifier s’il y a un bug dans le code qui nécessite une correction, ou quelque chose d’anormal dans votre base de données qui ne devrait pas y être. Ou bien les deux.
La trace mène à ce code dans app/serializers/current_user_serializer.rb
def has_new_upcoming_changes
last_visited = object.custom_fields["last_visited_upcoming_changes_at"]
return false if last_visited.blank? && object.created_at < Discourse.site_creation_date + 1.hour
cutoff = last_visited.present? ? Time.zone.parse(last_visited) : object.created_at
UpcomingChangeEvent.added.not_backfilled.where("created_at > ?", cutoff).exists?
end
On pourrait exécuter une requête d’explorateur de données pour voir quelle valeur de last_visited_upcoming_changes_at ont vos comptes d’administration.
SELECT
ucf.id AS custom_field_id,
ucf.user_id,
u.username,
ucf.name,
ucf.value
FROM user_custom_fields ucf
INNER JOIN users u ON u.id = ucf.user_id
WHERE ucf.name = 'last_visited_upcoming_changes_at'
AND u.admin = true
et cela pourrait être fructueux. Dans mon cas (récemment mis à jour vers v2026.7.3), il s’agit simplement d’une chaîne de date, ce que je pense qu’il devrait être.