Voici ce que j’ai obtenu :
- L’utilisateur crée un sujet
- L’utilisateur supprime le message du sujet, en planifiant la suppression (j’ai modifié le paramètre du site
delete_removed_posts_afterà1) - Le sujet est supprimé après le délai spécifié
- Le personnel restaure le sujet et revient à la version originale du message (seule la restauration ramènera le message avec le message « sujet retiré par l’auteur, sera automatiquement supprimé dans 1 heure sauf s’il est signalé »)
- Le sujet sera à nouveau supprimé après un certain temps
Ce qui se passe : Lorsqu’un utilisateur supprime son propre message de sujet, une propriété appelée user_deleted est définie sur true. Un tâche en arrière-plan nommée DestroyOldDeletionStubs s’exécute toutes les 30 minutes. Cette tâche exécute la fonction PostDestroyer.destroy_stubs, qui parcourt la base de données et supprime tous les messages ayant user_deleted défini sur true ainsi qu’un « minuteur de suppression » expiré.
Le problème : Lorsque le personnel restaure le message, user_deleted n’est jamais défini sur false. Ainsi, la prochaine fois que DestroyOldDeletionStubs s’exécute, le message sera à nouveau supprimé.
La solution : Je suis presque certain qu’il faudra ajouter une logique à la fonction staff_recovered qui définira user_deleted sur false (user_recovered le fait déjà). Voir discourse/lib/post_destroyer.rb at main · discourse/discourse · GitHub
La solution rapide : Restaurez le message du sujet et récupérez son ID, puis accédez à votre console Rails et exécutez :
Post.find_by_id(ID_DU_MESSAGE).update(user_deleted: false)
L’ID du message peut être facilement obtenu en ajoutant .json à la fin de l’URL d’un sujet. En utilisant cet exemple de sujet : https://meta.discourse.org/t/topic-keeps-getting-deleted/128013.json. L’ID du message du sujet est 632362.