why do i see the deleted topic
-
@pichalite oh dear, the sounds even worse. lol.
-
@pichalite Yeah. I just looked at the forums as a guest, I'd say that's pretty bad. Those topics shouldn't display on the list at all to regular users. I'm surprised it's never been suggested before, or fixed.
-
The reason behind this behaviour is that when we pull the list of topics, we don't know ahead of time which are deleted and which aren't. In addition, admins are able to see the content of these topics, whereas regular users are not. Lastly, users can have different "topics per page" settings.
Therefore this content isn't cacheable, and so if we wanted to hide deleted topics, we'd have to do the following:
- User A has topics per page set to 10, retrieve top 10 topics in category B
- Expand those 10 and discover 7 of them were deleted. (3 remain)
At this point we can either serve page 1 as a three-topic page (that's bad), or continue:
- poll for page 2, retrieve another 10
- Expand those 10 and discover 4 were deleted (9 remain).
- Repeat from #3 until we have 10 topics
Now, imagine if you have pages and pages of deleted topics. NodeBB would be churning and making multiple calls to the db just to retrieve page 1. That's an anti-pattern
Secondly, let's go from page 1 to page 2... how do we determine what topics are on page 2? We can't simply retrieve items 10-20 anymore, since 10-20 were actually part of page 1 now, once we factored in the deleted topics.
This kind of headache-inducing logic is why we have to show "This post is deleted!" or "This topics is deleted!".
Let's say we did cache it... then we'd have to store the cache per user (or per user postsperpage-group-hash, possibly), and then we'd have to deal with cache invalidation, plus the inevitable bug reports since this entire system is hugely fragile from the get-go.
... and that's at a high level, imagine how many more edge cases we'd have to account for, and much more complex it would be once we actually started coding it!
-
@julian wow.. thanx for the detailed reply, very well explained. love to know stuff like this
Keeping the things you said in mind, will it be too complicated to add a wie bit of code just to shift (or have an option to shift) the deleted topics into another category automatically, (eg trash ). Im not suggesting anything further than this, like a restore this post back to the original thread option (..no!). this automatic category change should take care of archiving deleted posts (if required) while also removing it from the user's view.
though, even without these, i would still love this forum but to the see an endless list of deleted, unclickable (spam)posts can kill the fun sometimes. its a bad ux
-
@connectkushal In the case of spam posts, we recommend purging them completely, since they're likely to not be restored anyway.
-
Couldn't you add display:none style to the posts that are deleted when the user doesn't have sufficient permission level?
-
@julian said in why do i see the deleted topic :
@connectkushal In the case of spam posts, we recommend purging them completely, since they're likely to not be restored anyway.
-
@HolyPhoenix that will create confusion.
The navigator in the header will be out of sync with topics/posts displayed on page.
If you are using pagination and set it to, say 20 per page and the page only displays 17 as the display:none is set for deleted posts. That will create confusion.
-
@pichalite said in why do i see the deleted topic :
@HolyPhoenix that will create confusion.
The navigator in the header will be out of sync with topics/posts displayed on page.
If you are using pagination and set it to, say 20 per page and the page only displays 17 as the display:none is set for deleted posts. That will create confusion.
There must be a way for pagination to know a deleted topic (not yet purged) still exist and retain the count, no? I don't know how it works so just guessing.
-
@charles as julian pointed out...
The reason behind this behaviour is that >when we pull the list of topics, we don't >know ahead of time which are deleted and >which aren't.
And subsequently, even code is applied to process the topics frm the list after they have been loaded again and again till the appropriate list is compiled, that too per page, it will eat up lots of resources and will be too complicated.
I think focus should be on how to show the deleted topic in a way that it has least hinderance to scrolling.. @julian will it be possible to hide the user pic of deleted posts ? And also
this topic has been deletedin smaller fonts? Not a great alternative but a blank space would atleast look better imo... -
Hmmm... Had not thought of that for sure when I mentioned the css idea. I'm no master of nodebb, but it would also seem possible to do an easy (light) calculation like Total Post Count - Deleted Post Count for loading that though.
-
@HolyPhoenix refer to julian's post above... it's not an easy calculation otherwise it would have been done already.
-
What is the reason why the thread controller does not query only the posts that are 'alive', i mean, the posts that are not deleted, so the pagination is only made at active posts instead of the whole set of posts?
In mongo you could make that query and it is a simple and fast condition, is it a restriction of using redis?
Edit: I mean something like this: http://stackoverflow.com/questions/19285804/use-where-clause-in-redis-to-query-value (i dont know redis at all, so forget it if it is a nonsense given the nodebb persistence layer).
-
It's possible to maintain another sorted list of only undeleted posts so that only undeleted posts are queried when a user can't see deleted posts.
-
Hiding the posts on the client side via css and re-calculating the count is still not as good UX as showing the deleted posts (of course, this is subjective), as the expectation is that when you load a page, you get a page of 20 posts (or whatever you set it to).
When page 1 has 20 posts, and loading page two only nets you 2 posts, that's kind of a "wtf" moment.
@pitaj's suggestion has merit, though it would mean we would have to account for an additional sorted set when creating/purging posts/topics, so that's a bit of extra data. Might be worth it though.
Ping @baris to poke holes in this theory