Un utilisateur a supprimé tous ses messages, dont l’un était le message “À propos” d’une catégorie. Nous avons restauré le message et changé la propriété au compte Système, cependant il apparaît toujours comme “supprimé” pour un Administrateur, et affiche une erreur lorsqu’un non-Administrateur visite le message :
Je ne suis pas sûr que cela fonctionne, mais essayez de reconstruire le HTML de la publication. Vous pouvez le faire en cliquant sur les 3 points – > Clé à molette → « Reconstruire le HTML ».
Lorsque vous utilisez le bouton Supprimer tous les messages sur la page d’administration de l’utilisateur, le sujet “à propos” est supprimé. (Dans d’autres cas, la propriété est transférée à @system)
Vous pourriez créer une nouvelle catégorie et y déplacer tous les sujets, puis supprimer l’ancienne catégorie. Mais c’est plus une solution de contournement qu’une correction.
Bien que je vienne de le reproduire sur mon site de test et que le restaurer l’ait fait revenir immédiatement, je ne suis donc pas sûr de la nature de ce problème particulier.
Il est possible d’échanger l’ID du sujet “À propos” avec un nouveau en utilisant la console Rails, mais la « nouvelle permutation de catégorie » pourrait être une option plus simple via l’interface utilisateur.
J’aurai peut-être besoin d’instructions étape par étape pour m’assurer que nous faisons la même chose. Il semble que l’utilisateur ait été supprimé plutôt que seulement les publications ?
Il y a deux problèmes particulièrement malheureux en combinaison.
Lorsque vous utilisez « supprimer tous les messages » sur la page d’administration de l’utilisateur, le message « à propos de la catégorie » est supprimé. (Mais vous pouvez le restaurer)
Lorsque vous avez supprimé des messages dont l’auteur est également supprimé, et que vous changez le propriétaire avant de restaurer le message, vous ne pouvez pas restaurer le message. (Comme solution de contournement, vous pouvez supprimer le sujet et le restaurer. Cela restaure le premier message)
Donc, lorsque vous :
créez un utilisateur de test et une catégorie de test,
faites de l’utilisateur de test le propriétaire du sujet « à propos de la catégorie »,
supprimez tous ses messages de la page d’administration de l’utilisateur,
(facultatif) créez un autre sujet appartenant à l’utilisateur de test,
(facultatif) répondez aux deux sujets en utilisant un autre utilisateur,
supprimez l’utilisateur de test,
changez la propriété du sujet « à propos » (et de l’autre sujet),
essayez de restaurer les messages,
vous recevez une erreur, car vous ne pouvez pas restaurer le message. Remarque : les réponses dans les sujets sont visibles par les autres utilisateurs, mais ils ne peuvent pas voir le premier message.
Oui, je crois que l’utilisateur a créé la catégorie.
“Reconstruire le HTML” ne semble rien avoir changé.
Je suppose que nous pourrions créer une nouvelle catégorie et faire un échange, cependant, cela signifierait-il que les utilisateurs qui se sont abonnés/ont mis en sourdine/etc. la catégorie d’origine devraient refaire cela avec la nouvelle ?
Je n’ai pas peur de la console Rails, donc si attribuer un nouveau topic_id est la manière la plus “correcte” de structurer les choses, alors je suis enclin à le faire. Mais j’apprécierais un peu d’aide avec les commandes spécifiques à exécuter ; serait-ce quelque chose comme Category.find(10).topic_id = 723… ?
D’un autre côté :
… peut-être est-ce un moyen plus rapide de résoudre le problème ? (Bien que je ne voie que “Archiver le sujet” et non “Supprimer le sujet” dans le menu de l’icône clé à molette…)
Je n’ai pas testé cela aussi minutieusement que d’autres ici (merci !!) mais il me semble que la correction pour le problème énoncé dans le premier post est assez simple.
ne pas autoriser la suppression des sujets “about” par l’administrateur utilisateur (par les modérateurs/administrateurs du site)
Lorsque ce qui précède est tenté, empêchez-le et affichez un message d’erreur informatif. Je déplace ceci dans Bug car c’est un bug que les sujets “about” puissent être supprimés dans le cas susmentionné.
Je viens de créer un utilisateur test et je l’ai utilisé pour créer une catégorie, puis j’ai supprimé l’utilisateur depuis l’administration des utilisateurs. Cela m’a permis de supprimer directement l’utilisateur même s’il avait un sujet. La paternité du sujet “about” a été transférée à l’utilisateur système ! Donc, au moins, ce cas d’utilisation semble assez sûr à cet égard.
J’ai également essayé le cas de l’auto-suppression (il faut d’abord rétrograder l’utilisateur pour voir le bouton de suppression de compte). La suppression de cet utilisateur a également attribué la paternité du sujet au système. De plus, je vois que la valeur par défaut pour delete user self max post count est définie sur 1, ce qui signifie que par défaut, il n’est pas possible pour un utilisateur de se supprimer s’il a plus d’un sujet. Nous sommes donc en sécurité de toute façon.
Et j’ai testé la suppression de l’utilisateur via l’administration des utilisateurs. Fait intéressant, tant qu’il n’y avait que le sujet “about”, je n’ai pas obtenu le bouton de suppression de post. Mais après avoir créé un deuxième sujet, j’ai obtenu le bouton de suppression de post. Le sélectionner et taper le long texte pour confirmer a ensuite fonctionné - j’ai pu supprimer les posts de l’utilisateur, y compris le sujet “about”. Enfin une reproduction !
Et enfin, j’ai également pu supprimer le sujet “about” en utilisant les actions groupées. Une autre reproduction ! Oups, je vois maintenant que je n’ai pas de reproduction de la suppression des sujets “About” par actions groupées. Cela ne fait que échouer silencieusement.
Compte tenu de ce qui précède, nous pouvons ignorer les cas de suppression d’utilisateur (via l’administration des utilisateurs et l’auto-suppression) car la paternité est attribuée au système.
J’ai également essayé de déplacer le message “à propos” vers un autre sujet. Cela fonctionne et un minuteur de suppression apparaît, mais le sujet n’est pas supprimé après x jours. Le minuteur disparaît simplement. Donc, cela fonctionne bien.
Cela pourrait bien l’empêcher de se reproduire à l’avenir.
Cela dit, comment dois-je me remettre de la situation actuelle, où les utilisateurs voient une page d’erreur lorsqu’ils essaient de lire le message “À propos” de cette catégorie, même si le message appartient à l’utilisateur system ?
Je n’ai encore rien essayé ; j’espérais que quelqu’un interviendrait avec soit “oui c’est la bonne commande” soit “non ne fais pas ça ça va tout gâcher”…
@alxndr pouvez-vous confirmer que vous auto-hébergez, et non que vous êtes sur notre hébergement ? Si vous êtes sur notre hébergement ou si vous passez à notre hébergement, vous pouvez contacter notre équipe pour obtenir de l’aide et l’un de nos techniciens vous aidera à résoudre ce problème.
Si j’étais à votre place, je créerais simplement une nouvelle catégorie et je déplacerais tous les sujets dans cette nouvelle catégorie. Cela semble le plus simple.
Si vous décidez d’expérimenter avec la console Rails ou l’API, vous êtes en territoire inconnu, alors assurez-vous de faire une sauvegarde complète de votre site d’abord au cas où vous auriez besoin d’annuler le changement !
Ha Vous semblez ne pas faire confiance à mes conseils @tobiaseigen
L’utilisation de l’API serait une option plus sûre que la console Rails, il n’est juste pas clair si elle réussirait à restaurer ce sujet particulier compte tenu des circonstances.
Je n’étais pas sûr que l’API fonctionnerait car j’ai été bloqué en essayant des choses similaires dans l’interface utilisateur, mais il semble que j’aie eu un certain succès ().
Dans ce cas, j’ai utilisé le point de terminaison pour récupérer le message plutôt que pour récupérer le sujet (ce que l’option de restauration dans le message essayait de faire) :
Le bouton « restaurer ce message » semble utiliser ce point de terminaison, mais il renvoie une erreur 403, avec errorThrown vide et textStatus : « error ».
Cependant, dites-vous que l’utilisation de cette même route via une API, et non l’interface utilisateur Web, a fonctionné ?
D’après mes tests, le bouton de restauration essayait d’utiliser le point de terminaison de récupération de sujet (/t/TOPIC_ID/recover) et renvoyait une erreur 403. Mais il semblait fonctionner lorsque j’utilisais la version de récupération de messages à la place.
Je ne sais pas comment identifier l’ID de chaque publication ; l’ID de catégorie est 10 et je pense que l’ID du sujet est 723 ? Mise à jour : Aha, je l’ai trouvé ! Il y a un data-post-id sur l’élément DOM <article>…
Je ne vois pas ce point de terminaison dans la documentation de l’API… devrait-il s’agir d’un PUT ? avec des données ? Mise à jour : oui un PUT, sans données — ça a fonctionné ! Merci @JammyDodger !!
Vous semblez ne pas faire confiance à mes conseils 
).