Version: 1.04, by Reven
Developer Last Online: Apr 2009
Category: Add-On Releases -
Version: 3.6.5
Rating:
Released: 08-20-2006
Last Update: 09-14-2006
Installs: 82
Uses Plugins
No support by the author.
Infraction PM User Override
This product will allow you to set a user from which all private messages sent to your members after infractions are given are from. If you wish for your moderators to remain anonymous, or don't wish your members to know the moderator that gave them an infraction, this will help.
Administrators, super moderators and moderators can all still see which moderators awarded each infraction in the normal way, but regular members cannot.
Features
Lets all moderators hand out infractions from a standard username to protect privacy.
Doesn't log moderator actions under the standard username, but as the moderator carrying out the actions.
Details
1 Product
6 Plugins
Update Tracker
No database edits, queries or connections.
Installation
Enter your Admin Control Panel and go to the Manage Products page under the Plugins & Products tab, then click Add/Import Product. Download the XML file attached to this post and then locate it on your computer on this page, then click Import. The product will now be installed automatically. Finally, enter the Plugin Manager page and edit the plugin named Set Important Variables under the Product : Infraction User Override section, and set the user ID and username of the account you wish to use to send the private messages, click Save and that's it!
Changelog
1.01 - Bug fix: users could see the moderator that gave them their infraction by clicking the red/yellow card next to the post on which the infraction was made. Staff still see the real moderator whome gave the infraction to the user on this page, but users no longer see this.
1.02 - Bug fix: users could see the moderator that gave them their infraction by going into their User CP and viewing the list. Users can now no longer see the read moderator, but instead the override user.
1.03 - Optimisation: hook placement for infractor user settings moved from global_start to infraction_start. There is no hook for infraction_start in the User CP, so the hooks are evaluated manually by the plugin usercp_infractioninfobit.
1.04 - Bug fix: plugin with Infractor user settings was not evaluating properly: users could see their infractor if they viewed their own profile.
Fatal error: Existing data passed is not an array
Called set_existing in **CENSORED URL**/htdocs/includes/class_dm_pm.php on line 528
Called post_save_each in **CENSORED URL**/htdocs/includes/class_dm.php on line 823
Called save in **CENSORED URL**/htdocs/infraction.php on line 726
in /includes/class_dm.php on line 235
I've traced this down to your plugin, I have no idea what it might be though, I just know that the infraction system works fine when I disable your plugin, and when I enable it, I get this error message each time I'm trying to issue an infraction.
Does the infraction happen, dispite the error? I.e. is the infraction you give listed in their profile, or is it never given out?
Have you got any other products/plugins/modifications which are making use of the PM system? Particularly anything using the hook 'private_insertpm_process'.
Finally, have you set a username and user id for the 'Infractor' account in the plugin 'Set Important Variables'?
Does the infraction happen, dispite the error? I.e. is the infraction you give listed in their profile, or is it never given out?
Have you got any other products/plugins/modifications which are making use of the PM system? Particularly anything using the hook 'private_insertpm_process'.
Finally, have you set a username and user id for the 'Infractor' account in the plugin 'Set Important Variables'?
nope, not using 'private_insertpm_process' in any other plugin/product.
The infraction does not happen, and yes, I've set both the userID and the userName (and they match, of course) =\
These are only one other plugin that are making use of the PM system, and it's hooks are:
Send PM on Thread Move -inlinemod_domovethread
-threadmanage_move_simple
I'm sorry, but I really don't see what is causing that problem. Is anyone else getting this problem?
It's weird because the only thing involved with the PM part of the product uses a vBulletin class function exactly as its supposed to be used. That goes for all of the plugins too - nothing being passed is not what it is supposed to be, and the only room for error as far as I can see is the user input bit - the 'infractor' username and userid which, you've said, is not the issue.
One suggestion is that you could try making the file edits listed here. That will not remove all references to the infractor-giving moderator, but it will stop the PM including their username.
I'm sorry, but I really don't see what is causing that problem. Is anyone else getting this problem?
It's weird because the only thing involved with the PM part of the product uses a vBulletin class function exactly as its supposed to be used. That goes for all of the plugins too - nothing being passed is not what it is supposed to be, and the only room for error as far as I can see is the user input bit - the 'infractor' username and userid which, you've said, is not the issue.
One suggestion is that you could try making the file edits listed here. That will not remove all references to the infractor-giving moderator, but it will stop the PM including their username.
I had the same error with 3.6.2 and uninstalled the hack because, frankly, it isn't that important to override the name. If it worked for 3.6.2 or there was a quick fix I would like to have it installed.
I had the same error with 3.6.2 and uninstalled the hack because, frankly, it isn't that important to override the name. If it worked for 3.6.2 or there was a quick fix I would like to have it installed.
I am also having the same problem, and same errors and will be forced to remove this until fixed.