It just returns hundreds of topics which contain thousands of ‘Auto-Bumped’ msgs, but doesn’t tell how many such msgs exist in how many topics.
So, I think, ultimately I’ll have to wield the axe in the ‘dark rooms’ of rails console only (which is a bit intimidating).
I’m a bit worrisome because it’ll affect thousands of topics/posts in one go. If only there were some select all button inside topics which would select all the bumping msgs together and we could delete those msgs with one click inside any topic. And if anyone wanted to delete all such msgs in All Topics with just one command only then he’d have to enter ‘rails’.
Would the 5th line of the rails command told by you would ask or prompt anything before deleting all those posts? Or would it just do what it has been told to do, without any warning etc, or chance of retrieval?
If possible, can we delete ‘bumping msgs’ from anyone topic first, instead of deleting from whole website?
Also, can you pls suggest/tell any rails command to view some samples of the posts which we’re going to delete?
Something like this in the data-explorer may help give an overview:
COUNT(p.id) AS count
FROM posts p
WHERE action_code = 'autobumped'
GROUP BY p.topic_id
ORDER BY count DESC
However, I’ll chuck in a word of warning about using the rails console to make changes like these on a live site if you’re inexperienced with it. You may want to spin up a test site and have a practice before diving in.
Yeah it did solve problem as much as offered by the designers/developers.
But I still would like to say that there should be some ‘Admin’ commandj, in the admin settings or in the topic being viewed, to select all 'duplicate (Auto-Bumped) msgs’ in any one topic or all topics and then remove them, whenever admin wished.
Perhaps you could hide those messages with CSS instead? Unfortunately, I don’t think the post-small-action widget currently includes the action type as a CSS class, so you can’t target bump messages specifically. Maybe a theme component could help?
I haven’t done any other testing, so I don’t know if there would be any other side effects. It’s possible that small-action-[...] classes might clash somewhere else in the application, in which case you should choose a prefix that is guaranteed to be unique.