J’ai un sujet sur mon site qu’une personne (appelons-la X) a publié, puis supprimé en raison d’informations erronées. Je l’ai restauré et j’ai demandé à X d’ajouter une correction sous leur message original.
Depuis, le sujet continue d’être supprimé. Je l’ai restauré à deux reprises et tout semblait correct, mais après un certain temps, il réapparaît comme supprimé.
Que se passe-t-il ?
Est-il possible que l’utilisateur en question continue de le supprimer ? J’ai eu des utilisateurs qui préféraient supprimer leurs messages plutôt que d’affronter l’« embarras » de se corriger.
Vérifiez votre journal (admin/logs/staff_action_logs) pour voir si l’utilisateur les supprime. Le journal affichera les messages qui ont été à la fois modifiés et supprimés… et par qui ils ont été supprimés. Vous pouvez également cliquer sur l’icône d’information pour plus de détails.
Certains utilisateurs ont changé d’avis quant au fait de garder un message pour cela et pour de nombreuses autres raisons. Parfois, c’est simplement une de ces situations où l’on estime qu’il vaut mieux oublier ce que l’on allait dire. Parfois, il faut simplement accepter leur raison, même si aucune n’est donnée. 
Les utilisateurs ne peuvent pas supprimer instantanément les sujets ou les publications. Tout ce qu’ils peuvent faire, c’est déclencher une suppression en attente de 24 heures, qui sera une intention publique indiquée dans le sujet ou la publication, comme ceci :
(publication retirée par l’auteur, sera supprimée dans 24 heures sauf signalement)
De plus, vous ne pouvez le faire pour les sujets que s’ils n’ont aucune réponse et que le sujet a moins d’un jour.
Cela nous arrive également lorsqu’un sujet est supprimé par le système, c’est-à-dire 24 heures après la suppression d’un message par son auteur, il est impossible de le récupérer ; même si nous le récupérons, il est à nouveau supprimé automatiquement après 30 minutes.
J’ai discuté avec l’utilisateur et, autant que je puisse comprendre, il ne le supprime pas constamment. Il a même été surpris par cela, car c’est lui qui m’a signalé le problème en premier lieu.
Voici à quoi ressemblent mes journaux :
(Merci @JimPas pour la suggestion !)
Des idées ? Plus de données que je puisse fournir pour aider à diagnostiquer le problème ? Il semble que @Pad_Pors ait peut-être rencontré quelque chose de similaire.
Quelqu’un a-t-il trouvé une solution depuis ? Nous rencontrons le même problème.
Un utilisateur a créé un sujet, l’a supprimé, a demandé sa réactivation, et maintenant le système continue de le supprimer (le sujet entier, car il s’agit du premier message).
Nous pourrions déplacer le contenu dans un nouveau sujet, mais dans ce cas, toute personne suivant l’URL originale sera redirigée vers une page indiquant que la page est introuvable.
Peut-on reproduire cela lundi @tshenry ?
Bonjour @AstonJ,
Pourriez-vous confirmer les étapes de reproduction ? Voici ce que je teste, mais je veux m’assurer que cela vous semble correct :
S’il y a quelque chose que je devrais faire différemment, n’hésitez pas à me le faire savoir.
Bonjour Taylor, le sujet a été publié en avril, mais voici ce qui semble s’être produit :
C’est seulement lorsque l’utilisateur a posté hier pour demander où était son sujet que nous avons découvert que cela se produisait.
Si vous avez besoin d’autres informations, n’hésitez pas à me le faire savoir (ceci est le sujet qui continue d’être supprimé, au passage).
Hmm. Je ne suis pas sûr de bien comprendre ce qui se passe à l’étape 1, mais en supposant que l’essentiel est qu’un utilisateur a créé un sujet, l’étape 2 semble impossible. Si je crée un sujet en tant qu’utilisateur normal, que je réponds à ce sujet, puis que j’essaie de supprimer mon premier message (celui du sujet), le premier message ne sera pas marqué pour suppression, ce qui est prévu par conception.
Dans mon cas, cela s’est déroulé comme suit :
Je ne suis pas sûr des délais.
Je peux confirmer que la même chose m’est arrivée à plusieurs reprises.
Donc, d’après ce que je comprends, le personnel n’a pas de bouton « restaurer » disponible sur le sujet d’un utilisateur normal lorsqu’il a été programmé pour suppression. Seul l’auteur original peut restaurer le message pendant la période d’attente. Quand vous dites que vous l’avez restauré, voulez-vous dire après que la suppression automatique a eu lieu ?
Ah oui, désolé Taylor ! Je suppose alors qu’ils ont supprimé le premier message, puis en ont créé un deuxième — ce qui, à ma connaissance, est possible.
Voici ce que j’ai obtenu :
delete_removed_posts_after à 1)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.
Aha, il faut corriger @eviltrout
Excellent travail d’enquête, @tshenry !
Bien joué Taylor 
Pour toute autre personne ayant besoin de ce qui précède, vous devrez d’abord annuler la suppression du post/sujet, sinon la recherche renverra nil.
Je rencontre toujours ce problème. Est-ce que ce travail pour définir user_deleted à false a obtenu une quelconque avancée ?
Existe-t-il une solution rapide ou une méthode de contournement pour les instances hébergées ?
Je dirais :