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…)
여기 다른 분들만큼 이 문제를 철저히 테스트해 보지는 않았습니다(감사합니다!!) 하지만 첫 번째 게시물에서 언급된 문제의 해결책은 꽤 단순해 보입니다.
사이트 관리자/운영자(모더레이터)가 사용자 관리(User Admin)에서 소개 주제(About topics)를 삭제하는 것을 허용하지 말 것
위와 같은 시도가 이루어질 경우 이를 차단하고 유용한 오류 메시지를 표시해야 합니다. 위에서 언급한 경우 소개 주제를 삭제할 수 있다는 것은 버그이므로, 해당 문제를 Contribute > Bug 카테고리로 이동시키고 있습니다.
방금 테스트 사용자를 생성하고, 그 계정으로 카테고리를 만든 후 사용자 관리에서 해당 사용자를 삭제해 보았습니다. 사용자가 주제(topic)를 가지고 있음에도 불구하고 사용자 관리에서 직접 사용자를 삭제할 수 있었습니다. 소개 주제의 작성자는 시스템 사용자(System user)로 변경되었습니다! 따라서 이 사용 사례는 적어도 이 측면에서는 꽤 안전한 것 같습니다.
또한 자기 삭제(self deletion) 사례도 시도해 보았습니다(계정 삭제 버튼을 보려면 먼저 사용자를 강등시켜야 합니다). 이 사용자를 삭제해도 주제 작성자는 시스템으로 넘어갔습니다. 또한 delete user self max post count의 기본값이 1로 설정되어 있다는 것을 확인했습니다. 이는 기본적으로 사용자가 주제 하나 이상을 가지고 있을 경우 스스로를 삭제할 수 없음을 의미합니다. 따라서 여기서는 어쨌든 안전합니다.
그리고 사용자 관리를 통한 사용자 삭제도 테스트해 보았습니다. 흥미롭게도, 소개 주제 하나만 있을 때는 게시물 삭제 버튼이 나타나지 않았습니다. 하지만 두 번째 주제를 생성한 후에는 게시물 삭제 버튼이 나타났습니다. 버튼을 선택하고 확인을 위해 긴 텍스트를 입력한 후 작동했습니다 - 소개 주제를 포함하여 사용자의 게시물을 삭제할 수 있었습니다. 드디어 재현(repro)에 성공했습니다!
마지막으로, 일괄 작업(bulk actions)을 사용하여 소개 주제를 삭제하는 것도 가능했습니다. 또 다른 재현 성공! 아, 이제 보니 일괄 작업으로 About 주제를 삭제하는 재현은 되지 않는 것 같습니다. 그냥 조용히 실패할 뿐입니다.
위 내용을 고려할 때, 사용자 삭제(사용자 관리 및 자기 삭제) 사례는 작성자가 시스템으로 넘어가므로 무시할 수 있습니다.
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 
).