Username Management - Control who can change Usernames plus history

<font size="4">Username Management - Version 1.04</font>

Hack: Username Management
Version: v1.04
Author: MarcoH64

Description
With this modification installed you can let your members change their own username, or let Staff members change the usernames of other members.

Also a history of previously used names for a member is kept.

Features
- Users can change their own username controlled by Usergroup Permissions. If needed a time limit between changes can be set.
- Staff can change the Username of other members. This is again controlled by Usergroup Permissions.
- Previously used Usernames of a member can be viewed in posts, by hoovering over their Username. This is also controlled by Usergroup settings
- Full searchable history of Username changes in AdminCP
- Fully Phrased
- Optimized for server performance
- Documented API for addon developers

Changelog
23-12-2005 v1.04
- Changed master="true" to false in cpnav file.
- Fixed bug where history was generated when running Update User Names from Update Counters

v1.03
- Changed the size of the 'mh_unm_changelimit' & 'mh_unm_changelimit' columns in the usergroup table
from TINYINT to SMALLINT to support values > 255

23-11-2005 v1.02 (maintenance release)
- Improved internal caching routines
- Added internal routine for retrieving the latest changed usernames
- Coders: Parameter value change for parameter '$overridelimit' in 'mh_unm_fetch_username_history'
This release is needed if you want to use some fo the new Addon's!!
Known issues: Coder documentation not complete, no examples are given, although the 2 released addon's can be used as examples.

22-11-2005 v1.01
- Fixed bug messing up Private Messages (thanks mini2)
- Fixed bug in install routine that would create a wrong tablename if using table prefixes
- Changed the internal caching routines
- Added more parameters to mh_unm_fetch_username_history for more flexibility for Addon coders
- Added extended information mode
- Created first version of the Coders documentation
Known issues: No example code for an Addon Plugin yet.

22-11-2005 v1.00
Initial release

Upgrades
Upload all files from 'upload' folder.
Install the new product file, choosing an overwrite install.

Notes
Copyright ©2005 MarcoH64
This Modification may not be redistributed in whole or significant part or changed without prior agreement of author.
Please don't forget to click Install.
If you like this work and would like to support the author, donations are always welcome at Paypal: Marcoh64 AT gmail.com

[dcpaq2xx]

Originally Posted by eNforce

How about adding a character limit option? Some of my members are starting to create very long usernames :P

Guys,

Just my personal opinion and a suggestion or advice.

Please keep the code hacks and modifications to a minimum, more code change in each hack is not good, start running into problems and it makes it harder to do VB version upgrades at a later date. I learned this from dealing with PHPBB. Too many modifications just to get a default installation of PHPBB to do what you want it to do, im sure Vbulletin could go the same way with the code hack issues if you modify it far enough.

What Im trying to say is lets not add anymore code changes to a hack then what the hack was originally designed to do, that way we keep the code modification to a minimum. If we want to add another feature and it really doesnt belong with that original hack, (restricting user name lenght in a user name change/user id history for example, especially if its already included in the admin cp) then create a seperate hack just for that feature. Some people may not want that "extra" feature included in the main hack thus reducing the amount of code alterations on their board.

The less code modification the better.

Doug

[Marco van Herwaarden]

I must say that i totally agree with this. If i get a request that doesn't fit the idea of the original hack, or would make the core hack unneeded difficult/heavy, or would only be used by a few users, then i would deny that request. (You can even check on some of my hacks where i have done this).

Also hacks should try to rely on basic standard vB settings. If there is a standard setting to limit the username length (and there is), and my hack would not follow that 'rule', i would change my hack to follow the limits set by standard vB (i didn't have time to double check yet). If it does follow the standard settings, but a second limit for usernames set by my hack was requested (as it seems here), then i will deny that.

[Marco van Herwaarden]

I just installed this hack on my development board again and tested this issue. My hack follows the username length limit as set in AdminCP->vBulletin Options->User Registration->Maximum Username Length.

If you want to limit the length of usernames, just set this setting. This will also restrict usernames when new members register.

No need to change my hack.

[Andreas]

Regarding the cpnav problems in conjunction with my Enhanced ACP Navigation Hack:

By setting mater="true", your XML effectively becomes the parent of navgroup users, if it is loaded before cpnav_vbulletin.xml - which is the case on UN*X-systems, but not on Windows:

[110] => Array
        (
            [Users] => Array
                (
                    [options] => Array
                        (
                            [10] => Array
                                (
                                    [Add New User] => Array
                                        (
                                            [displayorder] => 10
                                            [phrase] => add_new_user
                                            [link] => user.php?do=add
                                            [text] => Add New User
                                        )

                                )

                            [...]

                            [900] => Array
                                (
                                    [mh_unm_username_history_search] => Array
                                        (
                                            [displayorder] => 900
                                            [phrase] => mh_unm_username_history_search
                                            [link] => mh_unm_history.php
                                            [text] => Username History Search
                                        )

                                )

                        )

                    [group] => Array
                        (
                            [phrase] => users
                            [permissions] => canadminusers
                            [displayorder] => 110
                            [nav_file] => mh_unm
                            [text] => Users
                        )

                )

My code expects, that if a group is created by a cpnav XML other than vbulletin, that it is a custom group - hence Users disappears from the main page in this case.
You should not set master, if you are adding to existing groups.
Though I will modify my code to add an additional check for known vBulletin groups.

[Marco van Herwaarden]

Hmm a valid point. Will change this in the next version.

[WNxWakko]

Ok there is a problem. I ran Update Usernames in the Update Counters section of the admincp, and guess what it did? It marked every single member on the board that I changed their name. The log in profiles just say changed from and to the same name, but recorded a log showing I did it.

Also it looked bad on the addon whats going on bit where it shows recent changes. It not right here....

Any fix for this?

[WNxWakko]

Originally Posted by WNxWakko

Ok there is a problem. I ran Update Usernames in the Update Counters section of the admincp, and guess what it did? It marked every single member on the board that I changed their name. The log in profiles just say changed from and to the same name, but recorded a log showing I did it.

Also it looked bad on the addon whats going on bit where it shows recent changes. It not right here....

Any fix for this?

Bump. Any way to fix this?

[Marco van Herwaarden]

Sorry i just returned from a trip out of the country. I saw your reply in my mail and have already a fixed version for it. Will try to zip it up and release later today.

To provide also cleaning instructions to remove those history records that where added by updating the usernames, it would really help me if you could supply me with a dump of your history table (mh_unm_history) and you user table (only need the userid & username columns i guess.

[Marco van Herwaarden]

Version 1.04 released.

Changes:
23-12-2005 v1.04
- Changed master="true" to false in cpnav file.
- Fixed bug where history was generated when running Update User Names from Update Counters

v1.03
- Changed the size of the 'mh_unm_changelimit' & 'mh_unm_changelimit' columns in the usergroup table
from TINYINT to SMALLINT to support values > 255

[paulmjno]

You know what would make this hack perfect? If you could make it only for users who have been registered for a certain amount of time.