Version: 1.00, by bairy
Developer Last Online: Jul 2023
Category: Administrative and Maintenance Tools -
Version: 3.6.0
Rating:
Released: 09-23-2006
Last Update: Never
Installs: 32
Uses Plugins
No support by the author.
What does it do
There are two parts to this.
1. Allows you to specify users who cannot edit or delete their posts.
2. Has an optional trigger to catch people who delete or edit too many of their posts in too short a time. You specify the limits.
Why?
If you haven't had them already you probably will at some point: The tantrumers.
These are people who one day decide they hate you and/or your board, usually just after you've deleted one of their posts or pissed them off some how, and they'll want out. Instead of leaving quietly and gracefully they'll go on a mad rampage to edit/delete/both all their posts.
With 3.5/3.6's ajax, this is made very easy so they can do a fair bit of damage before you're able to stop them.
How does it work?
When a member goes to edit their post, either via the inline editor or the "full" editor, a check is made to see if they actually can. If they can't, they're shown an error message of your choice.
If they can, a check is made to see how many edits and/or deletions they have done recently. If it's "too many too fast" (the limits are specified by you), then they are stopped and an optional PM is sent to a member of your choice (probably to you) saying so, this is so the edits and/or deletions can be investigated.
Features
You can turn the whole system on/off
You can manually add users to the list.
Automatic trigger can be turned on/off. If it's on, you can specify the limits.
You can specify the message they recieve when they are disallowed.
You (or any member) can be sent a PM notifying you off a trigger being set off. The PM contains useful links by default.
You can exclude usergroups and individual users from the check.
Just one plugin.
Caveats
Thread Tools Dropdown > Thread Delete is not checked meaning if you allow a usergroup to utilise that feature, they can do it all they like.
Hard Deletions (physically removed) posts are not checked against. To do this would mean making a new table, and since I assume you trust people you give such power to, I have no desire to add such a check.
Adds one query every time edit is pressed. Adds between 1 and 4 more to the edit post script, dependant on what happens.
Private Message counts don't seem to be updating properly on my test board when a PM is sent. I'm using vB's own datamanager so I can only guess there's a bug with that.
To do
As soon as I figure out how, allow the messages to be phrased.
As soon as I figure out how, allow the optional PM to be sent to more than one member, e.g. two or more admins.
Possibly make a way for moderators to control who can and can't edit. Depends if there's enough demand.
Throw 'Thread Delete' into the check. There isn't a hook in an ideal place but it's possible. Depends if there's enough demand.
Support
Not much.
If there's a bug, I'll try and fix it.
If there's a way to edit or delete posts that I missed, I'll try and plug it.
If it clashes with another mod, I'll look at fixing it if it's an easy fix.
No "it doesn't work" support given. It works just fine on a clean install of 3.6.0 gold.
Screens
There's not really much to screenshot, so I've just taken a sample few.
options.png is the admincp options
Image1.png is the default "you can't" message for those who can't edit/delete.
Image2.png is the same message but in the inline editor (vB feature)
Image3.png is the default PM you get when someone sets off the trigger.
Show Your Support
This modification may not be copied, reproduced or published elsewhere without author's permission.
This hack is kinda designed to replace the editing time limit.
The time limit check is done before this plugin is reached, so it'd have to be flipped over so that everyone can edit any aged post but you can input usergroups that are limited by time.
It's a possibility but not something I'm planning at the moment. Perhaps in future.
I haven't tested it with 3.5 though for some reason I'm thinking it's not compatible. I'm not sure why, must have been a thought that came to me when I was coding it.
I haven't tested it with 3.5 though for some reason I'm thinking it's not compatible. I'm not sure why, must have been a thought that came to me when I was coding it.
Yes, it will work for 3.5.x if you delete in the product the line:
executionorder="2"
Thanks, good stuff!
Edit:
Aaarggll..., on issue left:
Invalid SQL:
SELECT dateline
FROM vb3_deletionlog
WHERE userid = 4549
UNION ALL
SELECT dateline
FROM vb3_editlog
WHERE userid = 4549
ORDER BY dateline DESC
LIMIT 4, 1;
MySQL-Fehler : Unknown column 'dateline' in 'field list'
Fehler-Nr. : 1054
Datum : Monday, November 27th 2006 @ 11:06:05 AM
Yes. 3.5's deletionlog doesn't have a dateline field.
I don't think the deletion date is recorded at all in 3.5.
a) You can't use this 3.6 product.
b) You can edit the code so it doesn't left join the deletionlog table, though that means that the "how many deletions have they done in the last x mins" won't work (meaning people can delete all they want), and makes the "how many edits and deletions have they done in the last x mins" more unreliable. However it will still be acceptable if people only edit, e.g. if you don't allow people to delete their posts.
Even with that fixed there may be other problems on 3.5
Per user Edit/Deletion flood control (plugin) Details »»
About Developer
Uses Plugins 
No support by the author.
09-27-2006, 07:33 AM
