Forum features

If some people vote the past as bad, it’ll be marked with a banner.

Red

If even more people rate it badly, banner and only the first few lines shown by default.

Intermediate I hadn’t considered.

And if it passes a threshold, it won’t be shown at all except to admins.

> 9 and you’re talking to yourself. Although past experience suggests that would just allow a big, choking build up of dross for some poor soul to remove, so unless the moderator intervenes let the automated element stop additional posts after an additional < arbitrary number >

From past experience (the mega spam incidents) I suspect that the facility to block like that doesn’t exist, or it’s a bit more than a trivial exercise to implement, otherwise it would already be there.

You would need to be careful that only users with a certain number of posts could downvote another user to prevent malicious new users from exploiting the system for harm.

That doesn’t solve the problem of us malicious old users though.

I suspect that the facility to block like that doesn’t exist, or it’s a bit more than a trivial exercise to implement,

The Beast website no longer exists (abandoned project), but at one time it proudly presented itself as a functional forum in the least lines of code possible.
So, yeah, to say it lacks facilities would be an understatement.
As far as I’m aware, it’s not even possible to tag a user ID and delete all the posts from that person without, like, hacking the underlying database.
The source code is available, for anybody that understands Ruby.

That doesn’t solve the problem of us malicious old users though.

There isn’t really a solution. Regard (political) voting, same problem…

There isn’t really a solution.

And there you have it. To so many things.

As far as I’m aware, it’s not even possible to tag a user ID and delete all the posts from that person without, like, hacking the underlying database.

That is in fact very easy to do: just delete the user.

Admittedly it gets done in a rather messy way: threads started by the now-deleted user disappear in their entirety, and if anyone tries to access one of the deleted threads they get the error message “Application error: Rails” instead of a 404.

Deleting a user does not delete their posts or topics started by them.

Deleting a user does not delete their posts or topics started by them.

In that case, the forum code has been updated since November of last year.

While I welcome this news, it is a little odd that no mention was made of the update (Changeset 481 – the most recent change – doesn’t seem to cover it at all, and Changeset 480 dates from 2020).

What makes you think it wasn’t done manually?
Noting that the person concerned chose to delete their account, to go and tidy up the mess?

What makes you think it wasn’t done manually?

Two reasons:

1. The user had posted some 2600 messages, all of which disappeared in a matter of hours.
2. Threads that he started disappeared in their entirety (replies as well as his postings) which removed a further 1800 messages written by other people. Of course this may be an unrelated bug.

If we posit an administrator manually deleting 2600 individual messages (and assuming 5 seconds per message deletion) that comes in at 3.6 hours elapsed. Achievable, but decidedly tedious.

If we posit an administrator manually deleting

There’s your problem right there.

Remember I said this:

hacking the underlying database

So… something like?

SELECT ALL TOPICS WHERE TOPIC_CREATOR = "Troll"
SELECT ALL MESSAGES WHERE MESSAGE_TOPIC = SELECTED
DELETE -withoutprejudice

SELECT ALL MESSAGES WHERE TOPIC AUTHOR = "Troll"
DELETE -withoutprejudice

DROP "Troll"
HARD
ON HIS BONCE
TWICE

I’ll let somebody else bash that into something that resembles coherent SQL.

Simpify.

Presume that messages with no valid author are marked as invalid and are hidden and marked for purge at next database clean/re-index.

So:

Delete account – trigger feature of display system for message database and hide all orphaned messages (of the thread originator)
Recursion – hide and mark for purge all orphaned replies.
Recursion – hide and mark for purge all orphaned replies…

I’ll let somebody else bash that into something that resembles coherent SQL.

What you are suggesting is pretty much exactly what happened on 07 November 2021, either automatically (when the user account was deleted) or by the admins running a database script. So it looks like the admins already have this one covered, one way or the other.

1. The user had posted some 2600 messages, all of which disappeared in a matter of hours.
2. Threads that he started disappeared in their entirety (replies as well as his postings) which removed a further 1800 messages written by other people. Of course this may be an unrelated bug.

Most likely is that the person in question invoked their right to be forgotten under the website privacy policy which says account deletion doesn’t by default delete history. Some database foo was clearly done behind the scenes to satisfy the request.

That left the question of what to do about threads the user had contributed to. It’d be a bit odd to come back to a linked thread and only find one half the conversation there (or people appearing to talk to themselves), so I guess the least bad option was to drop threads started by the user entirely, but not those where they’d merely commented part way through.