Inline Moderation Tools (v1.2.1)

Note: Development of this hack has stopped.
The built-in version is far superior to this hack and has better controls and permission checking. For those of you who will remain on 3.0.x, I will try to support this hack as best I can, but it won't be a top priority. If you plan on moving to 3.5, I hope this hack made your life a little bit easier while you waited .

Current Version: 1.2.1 (Wed Dec 11 15:26:30 PDT 2004)

What this is?
This hack will allow you and your moderators to do your job more effectively by allowing you to mass-moderate. You can perform the same action on multiple threads and posts without leaving the current page!

What is required?
In order to use this hack, you must have cookies and JavaScript enabled! If you don't, this hack will not work. (Note: there is no "alternative display" for people without JavaScript enabled).

How many changes?
Uploads: 2
File edits: 2
And template additions/edits

Support
I will provide all support here in this thread.

Bugs
I have thoroughly tested this hack with as many different combinations I could think of. But I probably have either over looked one or two, or just didn't think of some. If you find any odd behaviour, please let me know!

Changes Since

• 1.2.0
  • Fixed problems with merging threads
  • Enhancement to the merge thread screen
• 1.1.0
  • (Hopefully) resolved all JavaScript issues
  • Merge threads
  • Removed search results moderation ability (it was too much work to maintain and a user could bypass the protection if he knew how the hack operated)
  • Bug with not updating all user fields in post merge
  • Bug with checking for the wrong permissions when deleting a post
  • Template caching
  • Selection boxes only appear when a user is a moderator
• 1.0.0
  • Fixed search results
  • Added small announcement patch

Fixes For 1.2.1
The following fixes are in in the next version:

• Instructions typo for threadbit template
• Attachments are lost when merging posts The download has not yet been updated with this fix!

On The To-Do List

• Usergroup permission for inline moderation

If you'd like a moderator action added to this hack, post it below and I'll look into it.

What are the screen shots of?

• Thread listing with inline moderation
• Post listing with inline moderation
• Merge posts screen
• Result of merging posts
• Split thread screen

Don't forget to click install!!!

[Zoints]

That fixed it rob_daemon, thank you! Great support.

[rob_daemon]

Glad that fixed it up .

[Zoints]

Here's a troublesome bug. I found today when doing an IP search that some people were showing as having posted under other's IP's, including admin, supermods, and such. I thought there was an exploit until I investigated and found it was a bug with this hack. When merging posts, you use:

$DB_site->query("UPDATE " . TABLE_PREFIX . "post SET pagetext = '" . addslashes($_POST['finalpost']) . "', userid = " . intval($_POST['mergeuser']) . ", title = '" . addslashes(htmlspecialchars_uni($_POST['title'])) . "' WHERE postid = {$vars['newpost']['postid']}");

However, it just updates the userid, but not the username which wreaks all kinds of havok.

[rob_daemon]

Originally Posted by thegunowner149

Here's a troublesome bug. I found today when doing an IP search that some people were showing as having posted under other's IP's, including admin, supermods, and such. I thought there was an exploit until I investigated and found it was a bug with this hack. When merging posts, you use:

$DB_site->query("UPDATE " . TABLE_PREFIX . "post SET pagetext = '" . addslashes($_POST['finalpost']) . "', userid = " . intval($_POST['mergeuser']) . ", title = '" . addslashes(htmlspecialchars_uni($_POST['title'])) . "' WHERE postid = {$vars['newpost']['postid']}");

However, it just updates the userid, but not the username which wreaks all kinds of havok.

Thanks. I've set it to now update all the user-based fields. The new update should be coming either today or tomorrow .

[theArchitect]

Originally Posted by rob_daemon

Thanks. I've set it to now update all the user-based fields. The new update should be coming either today or tomorrow .

Sorry to bug you, I know that you are busy with School, but do you have an eta on the update?

[sv1cec]

I just installed this hack, and it is a God-send, thank you.

Just one suggestion, instead of using can_moderate(), why don't you use can_moderate($forumid, '', $bbuserinfo[userid])? In that way, the checkboxes etc. will appear only in the forums that the moderator can actually moderate. This works in forumdisplay, etc. In postbit and postbit_legacy, use can_moderate($forum[forumid], '', $bbuserinfo[userid]).

I also noticed a dangerous issue here. A moderator can delete a post, which is made by an administrator or a super moderator. I am sure you wouldn't like this happening. I am working on finding a way to prevent that.

Now, I am going to see what I can do about the search results thing.

Rgds
----------
John
SV1CEC

[rob_daemon]

For the first bit: yes, as I stated above the new version that I hope to release this weekend does take care of that by having a conditions that attend to that.

For the second bit: That's how the vB permission system works. If a moderator can delete posts, he or she is eligible to delete any posts, regardless of the users' rank.

[sv1cec]

Originally Posted by rob_daemon

For the first bit: yes, as I stated above the new version that I hope to release this weekend does take care of that by having a conditions that attend to that.

For the second bit: That's how the vB permission system works. If a moderator can delete posts, he or she is eligible to delete any posts, regardless of the users' rank.

Rob,

You are right on the last issue, I did some checks yesterday. It's not difficult however, to add some functionality over vB's standard permissions. For example, in my Advanced Warning Hack, I use an hierarchical warning schema, where the admins can warn everyone, the Super mods can warn mods and simple users and the mods can warn only simple users.

Actually, I had modified your code yesterday, enough to have it working like this, a simple mod couldn't delete an admin's thread or post etc. Then I screwed up something and had to remove the code from the forumdisplay and threadbits, but it still works in the postbit part. If you want, I can work with you on that, later today, it requires a couple of modifications in the forumdisplay query that gets the threads and then some conditionals in the forumdisplay, threadbit and threadbit_deleted templates.

I plan to do them for my system today, since the twins will be at their grandmother (peace of mind), so if you want, they are all yours.

Rgds
-------------

John

[rob_daemon]

Thanks for the offer, but I like to keep the permissions system based on the true vB3 permissions set to prevent confusion (both on my end and the users'). You're more than welcome to post the changes in the thread, though.

[sv1cec]

Originally Posted by rob_daemon

Thanks for the offer, but I like to keep the permissions system based on the true vB3 permissions set to prevent confusion (both on my end and the users'). You're more than welcome to post the changes in the thread, though.

I have one question. An admin of one forum cannot delete a thread from the forumdisplay, while he can from the thread tools within the thread. I checked your code in inlinemod.php and it appears that you are using the following conditional:

PHP Code:

if (!can_moderate($vars['forumid'], 'canremoveposts'))
{
    print_no_permission();
} 


Wouldn't that check for permanent deletion? I suppose that you should use candeleteposts, instead of canremoveposts, but I am not sure. Can you please clarify?

Rgds and tnx