![]() |
Yes, the current version does not cache the templates and I have fixed that. Currently the project is a mess in development and I'm trying to clean it up and release a new version which will fix a ton of bugs and add some features.
As far as limiting the power, they only have access to the tools that they'd have in the "Thread Tools" popup menu. Do you want to prevent them from using inline moderation all together? And don't forget to click install ;). |
Quote:
And I just licked install. *edit* and clicked it |
I have finally sourced the error that was causing the error in the inline.js file.
Code:
// ################################################################### // Set the name of the go button function write_button(avalue) Your help with this would be apprecaited. |
Nevermind, I got it figured out. Thanks again for a great hack.
|
theArchitect: when does this happen? Does he press the checkboxes or does this only occur when the page loads? Is he a moderator and does he have access to the inline tools?
thegunowner149: glad you got it working, the new version has a usergroup setting to control the usage of inline moderation tools. |
Quote:
He is not a moderator and does not have access to the inline tools. Hope this helps with the trouble shooting. |
I'll hopefully have the new version of the tools out by next Tuesday. Hopefully that'll fix the problem. It will not show any of the tool items or load any of the scripts unless the user has moderator powers in that specific forum. I'll also do some rigorous JavaScript testing in IE6 with high security settings, etc.
|
Quote:
|
I'm getting the same error as theArchitect. I can give a lot more information on it.
It only occurs with IE. It occurs when loading forumdisplay.php and showthread.php pages. MY exact error is: Code:
Line: 94 Ideas how to fix it? |
As I stated above, it will be fixed in the future. Thanks for the information :). This is the new version of write_button() in inline_moderation.js. Replace this:
Code:
// ################################################################### Code:
// ################################################################### |
That fixed it rob_daemon, thank you! Great support.
|
Glad that fixed it up :).
|
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:
Code:
$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']}"); |
Quote:
|
Quote:
|
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 |
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. |
Quote:
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 |
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.
|
Quote:
PHP Code:
Rgds and tnx |
Quote:
|
Thankyou for sharing your work with the community :)
|
Quote:
Tnx --------- John |
Quote:
|
Quote:
No hurry for me, I came up with my own version, but I would be interested to see how it compares with yours. If you need the code, please let me know. Rgds ----------- John |
I am not sure if someone would be interested in that, but I noticed that if you do a search and come up with the results, then you do an inline moderation action, like delete a thread (supposing you are allowed to do that), then you are no longer returned to the search results, but to the forums home page.
That bothered me, since I use the search to find all posts since yesterday, and I want to return there to check for more. What I came up with, is that you may catch up the fact that you called the inlinemod.php from the search results, and have the program return you there. All you have to do is to pass a hidden parameter from the search_results template form to inlinemod.php. Here is what you have to do: Open your search_results template and find: HTML Code:
<input type="hidden" name="unsafe" value="1" /> HTML Code:
<input type="hidden" name="searchid" value="$searchid" /> PHP Code:
PHP Code:
PHP Code:
PHP Code:
Rgds --------- John |
Alrighty! At long last, here it is! Inline Moderation Tools 1.2.0 should resolve all of the JavaScript users were having. Check boxes now only display when they need to, all templates are now cached, thread merging has been added (however, threads with polls it will not merge because it was too much work to figure out all of that logic), it removed search results moderation (sorry but this was a security hole that needed to be closed (if you want it enabled, I can explain how for you)), and a few other various fixes.
Upgrade instructions as well as fresh install ones are in the ZIP. Don't forget to click install! |
Quote:
Just change your instruction in global.php, it should say: PHP Code:
Rgds |
Great, thanks for the update :) And thank you for that fix sv1, dunno if I'd notice that on my own, well now we dont have to find out ;)
Small suggestion: Getting rid of the .DS_Store files to save zip space :p PS: I just wanted to say, whatever you did to the install HTML file, thank you! You have no idea how great it is to be able to use Crtl+A inside a textarea to fetch only the text inside that :D Oooh me happy now :D *ahem* Ill go away now :p |
Hello -
I've installed this hack, but for some reason nothing displays at all. Am I supposed to activate it someway? Please let me know! Thank you for your time and energy! |
Quote:
Raven: I guess that's a bug in my ZIP packager then for not removing .DS_Store. I'll get rid of it when I repackage the zip tonight. Glad you like the installer :D. I love being able to do Apple/Control + A to select all the text, too. It's so much easier :D. WebMasterAJ: If you are upgrading, make sure that in global.php the following: PHP Code:
PHP Code:
|
I think I found one more little thing. In the threadbit template, your instructions (at least for those upgrading from 1.1.0) ask us to enter:
HTML Code:
<if condition="can_moderate($thread['forumid'])"> HTML Code:
<if condition="(can_moderate($thread['forumid']) AND $show['inlinemod'])"> Rgds |
Quote:
|
Quote:
Rgds |
Okay, the ZIP should now be all fixed with those two problems with the instructions and the .DS_Store files are now removed :).
|
I am getting the following error when trying to merge two threads (IDs are: 1791 and 1793)
Database error in vBulletin 3.0.3: Invalid SQL: UPDATE subscribethread SET threadid = 1791 WHERE threadid IN (1793, 1791) mysql error: Duplicate entry '1-1791' for key 2 mysql error number: 1062 Date: Thursday 09th of December 2004 08:42:23 AM Script: http://forum.m1911.org/inlinemod.php Referer: http://forum.m1911.org/inlinemod.php Username: John IP Address: 62.38.176.245 Any idea? Rgds |
Try this:
Find from in ./inlinemod.php: PHP Code:
Replace all that with: PHP Code:
|
Quote:
Database error in vBulletin 3.0.3: Invalid SQL: UPDATE subscribethread SET threadid = 1799 WHERE threadid IN (1800) mysql error: Duplicate entry '1-1799' for key 2 mysql error number: 1062 Date: Thursday 09th of December 2004 11:16:10 AM Script: http://forum.m1911.org/inlinemod.php Referer: http://forum.m1911.org/inlinemod.php Username: John IP Address: 62.38.176.245 rgds |
Quote:
PHP Code:
PHP Code:
|
Quote:
Database error in vBulletin 3.0.3: Invalid SQL: UPDATE subscribethread SET threadid = 281 WHERE subscribethread IN (Array) mysql error: Unknown column 'subscribethread' in 'where clause' mysql error number: 1054 Date: Thursday 09th of December 2004 11:57:56 AM Script: http://forum.m1911.org/inlinemod.php Referer: http://forum.m1911.org/inlinemod.php Username: John IP Address: 62.38.176.245 |
All times are GMT. The time now is 04:07 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 | |
---|---|
|
|
![]() |
|
Template Usage:
Phrase Groups Available:
|
Included Files:
Hooks Called:
|