vb.org Archive

vb.org Archive (https://vborg.vbsupport.ru/index.php)
-   vBulletin 3.5 Add-ons (https://vborg.vbsupport.ru/forumdisplay.php?f=113)
-   -   Stop people mass deleting / editing their posts (https://vborg.vbsupport.ru/showthread.php?t=110918)

bairy 03-19-2006 10:00 PM
Stop people mass deleting / editing their posts
 
Recently I have had a couple of my members disagree with me. They've then decided they want to throw a fit and managed to edit or delete several dozen of their posts before I've spotted them and being able to stop it.

Therefore I've written this hack.

What it does:
Every time someone* edits or soft deletes a post of theirs, the time of that event is logged. The edit post script reads the last 5 times that user edited or deleted a (different) post and if they've done 5 edits/deletes in 10 mins it automatically puts them into a "can not edit" list.
The user of your choice (probably you) then gets a PM telling you they've triggered this auto and you can investigate it.
The list is in the admin control panel so you can remove (or if you like, manually add) people to it.

*Usergroups 5,6,7 (supermods, admin, mods) are excluded from the check.


Changes:
1 vB option (optional)
1 phrase addition
4 file edits (1 is optional but recommended)
4 SQLs to run


Downsides:
= You have to disable the ajax in-line editing, or the error message gets really messy for people who are on the "can't edit or delete" list.
OR There is one extra query per showthread.

= There is one more query on every initial edit post request, and 3 more if that post is saved.


Note that people in the list who can't edit do still see the edit button. This was deliberate as when clicked it will supply them with a message. I thought this better than confusion over where it is.


I'm not a great coder and my knowledge of vB is what I can pick up as I go. I have successfully got this hack working on my board and I think I've covered all the angles and so far as I can tell, it will work on any board. However, make sure you have a backup of your database, and backups of the files you're editing, just in case, and at this time I still consider the hack as beta.

I'll try to give support where I can but I'm not "officially" supporting it.


UPDATES

1.01: Minor update
1. Added TABLE_PREFIX to my queries.
2. In editpost.php,
PHP Code:
$pmdm->set_recipients('bairy'); 
became
PHP Code:
$pmdm->set_recipients('bairy', $movealongnothingtoseehere); 
(where bairy is the name you chose).
Previously php moaned there was no 2nd parameter for the set_recipients function, now there is and the fact it's blank doesn't matter in this hack.

1.02: Fixed the AJAX problem.
Using one query per showthread, vb will determine if the user is on the can't edit list. If they are, it will disable the ajax inline editor meaning if they click edit, they'll be shown the error message as it's supposed to look.
It won't execute if the inline editor is switched off.
Fix (which is in the updated txt attachment):

Open includes/class_postbit.php
Find (line ~913):
PHP Code:
        // can edit or delete this post, so show the link
            $this->post['editlink'] = 'editpost.php?' . $this->registry->session->vars['sessionurl'] . 'do=editpost&p=' . $this->post['postid']; 
Add Below:
PHP Code:
            // Bairy's "too fast too much editors" hack
            if (!is_member_of($vbulletin->userinfo, 5, 6, 7) AND !$this->registry->options['cannoteditupdated'] AND $this->registry->options['quickedit'])
            {    // If the list isn't updated and ajax inline editing is on, update the list. If ajax i-l-e is off, there's no need to.
                $cannoteditlist = $this->registry->db->query_first("SELECT value FROM ".TABLE_PREFIX."setting WHERE varname = 'cannotedit'"); // Refresh the list in realtime (not cached)
                $this->registry->options['cannoteditupdated'] = true; // as options is already globalised it seems a good idea to use it instead of making another entire variable
                $this->registry->options['cannotedit'] = explode("|", $cannoteditlist['value']);
                if (in_array($this->registry->userinfo['userid'], $this->registry->options['cannotedit'])) { $this->registry->options['quickedit'] = false; }
            }
            // Bairy's "too fast too much editors" hack 

Stangsta 03-20-2006 09:34 PM
Good Job! But I cant use it. Im not going to disable AJAX nor do file edits :(

However, ill keep checking back for a plugin.

bairy 03-20-2006 09:48 PM
You don't have to disable the whole of AJAX, just the in-thread editing (when you click edit, it's the text box that comes up).
You don't even have to disable that if you don't want to, it's just that anyone who happens to trigger the limiter will have the warning phrase appear, header n all within the thread, which looks really horrible.
If anyone knows a way to force a page refresh and then show the error message when you click "save" on the in-line editor, I'll stick it in.

At the moment I don't know how I could disable AJAX for those members.

As for vB plugins, you're outta luck. The places I've edited don't have hooks anywhere near them.

LincolnForums 03-20-2006 11:02 PM
Why not just disable the feature where users can delete their own posts, and have it so they cant edit them after a certain amount of time?

Tralala 03-20-2006 11:08 PM
Quote:
Originally Posted by LincolnForums
Why not just disable the feature where users can delete their own posts, and have it so they cant edit them after a certain amount of time?
Because that throws the baby out with the bathwater. It may be okay to delete or edit a post from time to time, but NOT OKAY to edit or delete them all in a anger-ridden frenzy...

bairy 03-20-2006 11:14 PM
I did think about not allowing editing after a certain amount of time, but then I looked at the timestamps on the edit logs and found that a lot of people were editing days and even weeks after the original posts, usually to add a new photo of themselves or something.

It was an option but not ideal enough. This solution, although fiddly and not without drawbacks, was much more ideal (for me, at least)

With the deleting I personally feel users should be able to delete their own threads if they like.

COBRAws 03-21-2006 12:46 AM
This is a GREAT modificatioN! I hope you get some help over the AJAX problem so this wil become a better hack without those downsides.

Good luck! Ill install just to keep track of updates.

Snake 03-21-2006 10:24 AM
Nice work man!


All times are GMT. The time now is 04:21 AM.

Powered by vBulletin® Version 3.8.12 by vBS
Copyright ©2000 - 2025, vBulletin Solutions Inc.

X vBulletin 3.8.12 by vBS Debug Information
  • Page Generation 0.01114 seconds
  • Memory Usage 1,760KB
  • Queries Executed 10 (?)
More Information
Template Usage:
  • (1)ad_footer_end
  • (1)ad_footer_start
  • (1)ad_header_end
  • (1)ad_header_logo
  • (1)ad_navbar_below
  • (4)bbcode_php_printable
  • (1)bbcode_quote_printable
  • (1)footer
  • (1)gobutton
  • (1)header
  • (1)headinclude
  • (6)option
  • (1)post_thanks_navbar_search
  • (1)printthread
  • (8)printthreadbit
  • (1)spacer_close
  • (1)spacer_open 
Phrase Groups Available:
  • global
  • postbit
  • showthread
Included Files:
  • ./printthread.php
  • ./global.php
  • ./includes/init.php
  • ./includes/class_core.php
  • ./includes/config.php
  • ./includes/functions.php
  • ./includes/class_hook.php
  • ./includes/modsystem_functions.php
  • ./includes/class_bbcode_alt.php
  • ./includes/class_bbcode.php
  • ./includes/functions_bigthree.php 
Hooks Called:
  • init_startup
  • init_startup_session_setup_start
  • init_startup_session_setup_complete
  • cache_permissions
  • fetch_threadinfo_query
  • fetch_threadinfo
  • fetch_foruminfo
  • style_fetch
  • cache_templates
  • global_start
  • parse_templates
  • global_setup_complete
  • printthread_start
  • bbcode_fetch_tags
  • bbcode_create
  • bbcode_parse_start
  • bbcode_parse_complete_precache
  • bbcode_parse_complete
  • printthread_post
  • printthread_complete