A user deleted all their posts, one of which was the “about” post for a category. We restored the post and changed the ownership to the System account, however it still appears “deleted” to an Admin, and shows an error when a non-Admin visits the post:
Though I’ve just repro’d on my test site and undeleting it made it come straight back again, so I’m not sure what this particular issue is.
It is possible to swop the topic_id of the About topic to a new one using the Rails console, but the ‘new category switcheroo’ might be an easier option through the UI.
There are two problems that are particularly unfortunate in combination.
When you use “delete all posts” at the user’s admin page, the “about the category” post is deleted. (But you can undelete it)
When you have deleted posts where the author is also deleted, and you change the ownership before undeleting the post, you cannot undelete the post. (As a workaround you can delete the topic and undelete it. This undeletes the first post)
So when you:
create a test user and test category,
make the test user the owner of the “about the category” topic,
delete all their posts from the user’s admin page,
(optional) create another topic owned by the test user,
(optional) reply to both topics using a different user,
delete the test user,
change the ownership of the “about” topic (and the other topic),
try to undelete the posts,
you receive an error, because you cannot undelete the post. Side note: the replies in the topics are visible for other users, but they cannot see the first post.
“Rebuild HTML” doesn’t seem to have changed anything.
I suppose we could create a new category and do a switcheroo, however would that mean that users who’ve subscribed/muted/whatever the original category would need to re-do that with the new one?
I’m not scared of the Rails console, so if assigning a new topic_id is the more ‘correct’ way to structure things then I’m leaning towards doing that. But I’d appreciate some hand-holding with the specific commands to run; would it be something like Category.find(10).topic_id = 723 …?
On the other hand:
…perhaps this is a quicker way to solve? (Although I just see “Archive Topic” and not “Delete Topic” in the wrench-icon menu…)
I have not tested this as thoroughly as others here (thank you!!) but it seems to me the fix for the stated problem in the first post is fairly straightforward.
do not allow deletion of about topics on user admin (by site moderators/admins)
When the above is attempted, prevent it and display an informative error message. I am moving to bug because it is a bug that the about topics can be deleted in the above case.
I did just create a test user and used that to create a category, and then deleted the user from the user admin. It allowed me to delete the user directly even though it had a topic. The about topic authorship was given over to the system user! So at least that use case seems to be fairly safe in this regard.
I also tried the self deletion case (have to demote the user first in order to see the delete account button). Deleting that user also gave topic authorship to system. Also, I see that the default for delete user self max post count is set to 1, which means that by default it is not possible for a user to delete themselves if they have more than one topic. So we are safe here anyway.
And I tested deleting the user via user admin. Interestingly, as long as there was only the one about topic I did not get the post delete button. But after creating a second topic I did get the post delete button. Selecting it and typing in the long text to confirm then worked - I was able to delete the user’s posts including the about topic. Finally a repro!
And finally, I was also able to delete the about topic using bulk actions. Another repro! Oops, now see that I do not have repro of bulk actions deleting About topics. It just fails to do so silently.
Given the above, we can ignore the user deletion (via user admin and self-deletion) cases because the authorship is given to system.
I also tried to move the about post to a different topic. It works and then a delete timer shows up but the topic is not deleted after x days. The timer just disappeares. So this works okay.
This may well prevent it from happening in the future.
That said, how should I recover from the situation now, where users see an error page when trying to read the “About” post for this category, even though the post is owned by the system user?
I have not tried anything yet; I was hoping for someone to chime in with either “yes that’s the correct command” or “no don’t do that it’ll ruin everything” first…
@alxndr can you confirm you are self-hosting, not on our hosting? If you are on our hosting or switch to our hosting, you can reach out to our team for support and one of our tech associates will help you get this fixed up.
If I were in your position, I’d just create a new category and move all the topics into the new category. That seems the most straightforward.
If you decide to experiment with the rails console or the API you are in uncharted territory, so be sure you do a full backup of your site first in case you need to revert the change!
Ha You sound like you don’t trust my advice @tobiaseigen
Using the API would be a safer option than the rails console, it’s just not clear if it would successfully undelete this particular topic due to the circumstances.
I wasn’t confident the API would work as trying similar in the UI was blocked, but I seem to have had some success ().
In this case, I used the endpoint to recover the post rather than recover the topic (which is what the undelete option in the post was trying to do):
From my test, the undelete button was trying to use the topic recover endpoint (/t/TOPIC_ID/recover) and was throwing the 403. But it seemed happy when I used the posts recover version instead.
I’m not clear on how to identify the individual Post’s ID; the Category ID is 10 and I think the Topic ID is 723? Update: Aha, found it! There’s a data-post-id on the <article> DOM element…
I don’t see this endpoint on the API docs… should it be a PUT? with any data? Update: yes a PUT, with no data — it worked! Thank you @JammyDodger !!
You sound like you don’t trust my advice 
).