Impossible de restaurer les descriptions de catégories créées par un utilisateur supprimé

Contribuer Bug
1

À un moment donné, après la création de certaines catégories, l’utilisateur qui les avait créées a été supprimé. En examinant le journal, je constate que Discourse a automatiquement supprimé ces publications au même moment que la suppression de l’utilisateur.

Nous n’avons remarqué que cela posait des problèmes que bien plus tard, lorsque nous avons réalisé que, bien que les administrateurs puissent toujours voir (et modifier) les publications de description des catégories concernées, les utilisateurs ordinaires qui tentent de consulter ces publications obtiennent le message suivant : « Erreur ; lors du chargement ; Quelque chose s’est mal passé. »

Ces publications de description de catégories apparaissent avec un fond rouge. Je peux voir qu’elles ont été supprimées et à quel moment. Je vois le bouton « Restaurer », mais cliquer dessus ne produit aucun effet.

Si je vais dans les paramètres de l’une des catégories concernées (en cliquant sur son bouton Modifier) et que je clique sur le bouton Modifier la description, je suis redirigé vers la publication supprimée correspondante. Je peux apporter des modifications et les enregistrer ; après avoir actualisé la page, la nouvelle description apparaît. Cependant, les utilisateurs non administrateurs ne peuvent toujours pas voir le contenu de la publication (seulement l’erreur).

J’ai réussi à changer le propriétaire de l’une des publications pour le compte administrateur, mais le bouton « Restaurer » ne fonctionne toujours pas.

J’ai trouvé des rapports similaires sur meta Discourse, mais aucun des conseils donnés n’a jusqu’à présent fonctionné.

J’ai trouvé une référence à une personne ayant pu restaurer une publication similaire en utilisant l’API Discourse. J’ai donc commencé à m’y intéresser, mais je n’ai pas réussi à trouver d’informations sur la restauration de publications dans la documentation de l’API. Voir Can't recover a topic by a deleted user

J’espère qu’il existe une solution qui ne nécessite pas de recréer entièrement les catégories concernées.

Mise à jour : lorsque je clique sur le bouton « Restaurer » pour l’une de ces publications, une entrée est générée dans le journal des erreurs :

Url: mysite/assets/ember_jquery-189e46ebcb33594b835e782fd1ce916ec750bc0cf980ebc4fb7796649161a18d.js
Line: 1
Column: 266460
Window Location: mysite/t/about-the-showcases-and-use-cases-category/28```
3 « J'aime »
2

Quelqu’un a donc lancé une commande de suppression sur l’utilisateur qui a créé les catégories ? Y a-t-il une raison particulière pour laquelle cet utilisateur a été supprimé plutôt qu’anonymisé ?

Il est vrai que le sujet de description de la catégorie sera détenu par l’utilisateur qui crée la catégorie, de sorte que la suppression de cet utilisateur (et de tous ses messages) pourrait potentiellement causer cela. @tshenry, pouvons-nous tester ce scénario la semaine prochaine ?

3 « J'aime »
3

J’ai pu le tester rapidement tout à l’heure et reproduire les mêmes résultats.

  1. Créer une catégorie avec un utilisateur administrateur
  2. Révoquer son statut d’administrateur et supprimer l’utilisateur
  3. Le sujet « À propos » de la catégorie est supprimé de manière douce (soft-delete) lorsque l’utilisateur est supprimé
  4. Tenter de restaurer/désupprimer le sujet ne fonctionne pas
  5. Changer le propriétaire fonctionne techniquement, mais le sujet reste dans un état supprimé étrange, peu importe ce que vous faites depuis l’interface utilisateur.

Depuis la console, il semble que l’enregistrement posts associé au sujet soit supprimé lorsque l’utilisateur est supprimé. L’enregistrement du sujet contient beaucoup de zéros lors de l’examen de divers attributs liés aux publications.

Il pourrait être utile de demander à un ingénieur de voir si nous pouvons gérer cela de manière plus élégante, mais je soupçonne que c’est plus facile à dire qu’à faire.

J’ai pu trouver une solution de contournement pour revenir à un état fonctionnel, mais j’ai dû utiliser la ligne de commande. @jrivettcsa, je vous recommande de faire une sauvegarde avant d’essayer ceci :

Valeurs nécessaires

Assurez-vous de copier tout le contenu du sujet « À propos » que vous souhaitez conserver dans un bloc-notes ou similaire, puis procédez comme suit :

Accédez à la console Rails

cd /var/discourse
./launcher enter app
rails c

Remplacez <ABOUT_TOPIC_ID> dans la commande ci-dessous par l’ID du sujet « À propos » de la catégorie, puis exécutez pour supprimer définitivement le sujet cassé.

Topic.where(id: <ABOUT_TOPIC_ID>).destroy_all

Appuyez sur la touche q pour revenir à la console si nécessaire.

La catégorie est toujours associée au mauvais sujet, nous devons donc le nettoyer. Remplacez <CATEGORY_ID> dans la commande ci-dessous par l’ID de la catégorie, puis exécutez.

Category.where(id: <CATEGORY_ID>).update_all(topic_id: nil)

Appuyez sur la touche q pour revenir à la console si nécessaire.

Quittez la console Rails et exécutez la tâche rake suivante pour créer un nouveau sujet « À propos » pour la catégorie :

exit
rake categories:create_definition

Cette catégorie devrait maintenant être réparée ! Vous pouvez répéter l’opération au besoin.

6 « J'aime »
5

Oui, certaines modifications regrettables ont été apportées par quelqu’un qui aurait dû savoir mieux. Je ne peux en dire plus. Heureusement, ces événements sont enregistrés par Discourse.

1 « J'aime »
6

Merci d’avoir confirmé le problème et fourni une solution. Je vais tenter de l’appliquer et publier les résultats ici.

1 « J'aime »
7

Cette solution a parfaitement fonctionné. Merci !

J’ai corrigé chaque élément individuellement, mais je pense que j’aurais pu exécuter les commandes destroy_all et update_all dans une seule session de console Rails, puis lancer la commande rake categories:create_definition une seule fois à la fin. Qu’en pensez-vous ? Cela pourrait faire gagner quelques minutes à quelqu’un un jour.

4 « J'aime »
8

C’est définitivement un bug @jrivettcsa — quand la suppression d’un utilisateur peut entraîner un dysfonctionnement du site, c’est problématique ! Nous allons le corriger.

4 « J'aime »
11

Merci d’avoir signalé ce problème. J’ai apporté une correction dans cette PR :

Lorsqu’un utilisateur est supprimé, le message décrivant la catégorie n’est plus supprimé. À la place, l’auteur du message est modifié, passant de l’utilisateur original à l’utilisateur système.

4 « J'aime »