What is the reason behind making a user wait 15 seconds to report posts? I often hit that limit and skip reporting a bad post because I don't want to wait for 15 seconds to expire so I keep on reading threads....
I imagine if someone was abusing the reporting feature you could just penalize the user?
Jump to PostIt could help stop it flooding with bot posts or something though.. Otherwise they could make loads.. It could overwhelm the admins :P
Jump to PostMore annoyingly, its like that for mods. I like to get like 10-20 spam threads all up in one go and delete them all, but i cant, because when you infract someone, it makes a thread, and sends a PM, incurring a wait. grrrrrrrrrr. have mentioned this to dani before.
Jump to PostI dont think its actually bots anyway methinks its people who get paid to do it.
Jump to PostConsidering mods aren't ever bots, I think it'd be safe to write a quick script to let them do their job quickly. (It can't be that hard to write a check for the user's usergroup?)
It could help stop it flooding with bot posts or something though.. Otherwise they could make loads.. It could overwhelm the admins :P
Bots can also be programmed to avoid the delay resulting in the same problem. But us mere humans have to anxiously wait out delay :(
Yeah.. im just saying a bot could be a lot more a nuisance if it was able to report 3 posts a second or something. That would clog up the system. So it gives the admins time to reel in the bot before it gets to annoying.
More annoyingly, its like that for mods. I like to get like 10-20 spam threads all up in one go and delete them all, but i cant, because when you infract someone, it makes a thread, and sends a PM, incurring a wait. grrrrrrrrrr. have mentioned this to dani before.
When you infract someone and when you report a post, both, it creates a new thread. There are server resources consumed when adding a thread to the database, and therefore flood protection is necessary or else it could potentially take down the database. Especially with something such as reporting posts, which isn't limited to mods-only ... there's no way of knowing for sure whether or not it's automated. Someone could set up a greasemonkey script, couldn't they? (Unless I'm thinking of something else???)
Yeah but cant you reduce the infraction wait for mods to like 5s?
Likewise as those people who constantly post those threads about DVD players they could just create a single account and post a new thread every time instead of using one account for multiple threads. To me it seems the only people restricted by the 15s limit is humans. Bots can get around it. Even then if it is a bot then ~5s is reasonable for a human but would stop a bot that was mass spamming if that is how the spam software was authored.
I dont think its actually bots anyway methinks its people who get paid to do it.
Considering mods aren't ever bots, I think it'd be safe to write a quick script to let them do their job quickly. (It can't be that hard to write a check for the user's usergroup?)
> there's no way of knowing for sure whether or not it's automated.
> Someone could set up a greasemonkey script, couldn't they?
I'd again like to suggest what I initially suggested for the "Tags" feature. Instead of having a blanket rule applicable to all, the time duration should be configurable. E.g. Newly registered/those with less than 50 posts/those with less than 30 rep would need to wait for 15 seconds but the duration would be relaxed for those who satisfy the criteria to let's say 5 seconds? This should take care of the scripted attack issue.
The time requirement is a single built-in vBulletin setting which is used throughout the code as a flood check for anything that requires any type of database inserts to our most heavily stressed tables (post and thread tables).
Also, you're missing the point that if even a handful of people did use the feature every five seconds, the database would most likely end up very overstressed. It is set to 15 seconds because that is what our servers can currently bare.
> Also, you're missing the point that if even a handful of people did use
> the feature every five seconds, the database would most likely end up
> very overstressed
That's why I mentioned "This should take care of the scripted attack issue". If you are having database performance issues, the current system is good to go.
Database performance is always our number one concern because we currently don't have a clustered database system ... which is something we're currently looking into, because the clock is ticking with our current setup.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.
