Sure, abusing reports could result in a ban. Neither your solution nor mine has anything like automatic banning, so where is your added simplicity? As a matter of fact, your solution will actually not help admins see which users are abusing the reporting functionality since there is no way to trace which user has reported which post. It's lacking that entity that I told you you'd need., whereas my solution has a feature to automatically, without moderator intervention, take away reporting rights from those that abuse it.
Now here come the overly complex slashdot like algorithms:
Assuming the user table has a field ReportingScore
Assuming there is a PostReport entity with the following fields:
UserId
PostId
Remark (optional)
Timestamp
State (actual, processed)
// On the forum page, extra code:If User.ReportingScore > -5 // can be tweaked.
and Post.Timestamp > Today - 40 // to be tweaked, let's not let old posts be reported
Show report post button
end if
// Report post page:A simple form, displaying original post with a remarks entry box and an ok / cancel button. No algorithms other than 'add row to PostReport entity'
(with additional check if logged in user has an ok ReportingScore)
// Post report confirm page: duh
// Reported users page:select PostUser.Name, sum(User.ReportingScore) Score,
from PostReport, User, Post, User PostUser
where PostReport.UserId = User.UserId
and PostReport.PostId = Post.PostId
and Post.UserId = PostUser.UserId
and PostReport.State = actual
and PostReport.TimeStamp > Today - 10
and User.ReportingScore > 0
group by PostUser.Name
order by Score Desc
//
Display each record, plain and simple, and offer drilldown to a ReportedPostsPerUser page
// Reported posts per userselect PostId, sum(User.ReportingScore) Score,
from PostReport, User, Post
where PostReport.UserId = User.UserId
and PostReport.PostId = Post.PostId
and PostReport.State = actual
and PostReport.TimeStamp > Today - 10
and User.ReportingScore > 0
and Post.UserId = "page parameter's user id"
group by PostId
order by Score Desc
//
Display the posts with additional existing queries.
The page could offer an option to ban the user and delete the post in one fell swoop. That would then go along the lines of:
// Fast-ban user:select whatever
from PostReport, User, Post
where PostReport.UserId = User.UserId
and PostReport.PostId = Post.PostId
and PostReport.State = actual
and Post.UserId = "page parameter's user id"
//
foreach row
update user table, increase ReportingScore by one
if post not deleted, or --nuked--, do so
update report set state = processed
end foreach
// Deal with user still with existing methods
// Reported post details pageselect PostReport.Remarks, User.Name, User.ReportingScore,
from PostReport, User, Post
where PostReport.UserId = User.UserId
and PostReport.PostId = Post.PostId
and PostReport.State = actual
and Post.PostId = "page parameter's post id"
order by User.ReportingScore Desc
//
display post
foreach row
display User.Name, User.ReportingScore, PostReport.Remarks
end foreach
Display buttons: .. let's see.. temp-ban-user, ban-user. nuke-post. no-action-but-reports-good, no-action-reports-bad.
All buttons but the last one end up with an already existing action, and the 'good reports algorithm'. The last button triggers the 'bad reports algorithm'.
// Good reportsselect PostReport
from PostReport
where PostReport.PostId = "page parameter's post id"
//
foreach row
increase user's ReportingScore by 1
update PostReport set state = Processed
end foreach
// Bad reportsselect PostReport
from PostReport
where PostReport.PostId = "page parameter's post id"
//
foreach row
decrease user's ReportingScore by 1 // or 2... heheh!
update PostReport set state = Processed
end foreach
//
//and take that extra action depending on which button is pushed
// Top/bottom reporting usersselect top 10 User.Name, User.ReportingScore // or bottom 10
from User
order by User.ReportingScore
//
display rows
That about sums it all up. I wrote it in one stretch over the course of one and half hour (dealing with playing kids around here..) There's some extra thought put in the usability here and there that I am not bothering to detail now. Oh yeah, I could have made errors.. pseudocode is so hard to debug. Oh and if you could point out the overly complex slashdot-like algorithms, that would be dandy.
Show nested quote +On January 17 2009 12:04 onepost wrote:
With all due respect, I don't like your idea at all, and I'm sure TL's coders wouldn't either...
I wouldn't be so sure about that.. Look at the above pseudocode. 90% of it is already required for implementing your idea, my additional feature is 10% of the code. (no I didn't actually count, but in terms of implementation time, that's my overly negative estimate. Yes I am a programmer, I am trained to make negative estimates ;-) )