vBulletin Mods

Username Management - Version 1.04

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

If you are running version 1.00 and have problems viewing your Private Message, please apply the following fix (thanks to mini2 for pointing it out and providing the fix):
Goto AdminCP->Plugin System->Plugin Manager.
Click on Edit behind plugin 'Add Username history to postbit(legacy)'
In the Hook Location dropdown, change 'postbit_display_complete' to 'postbit_factory' (2 lines higher) and Save. All should be fixed now.

Better is to upgrade to 1.01, all known problems have been fixed.

Awesome.. This will certainly be useful for my future plans (premium users). :D

this hack rawks. And I got the second post. Yay!

Edit. Dangit I was too slow! :nervous:

Then please click Install ;)

Awesome. I am definitely going to install this hack for all my premium users too! :) Thanks.

One thing, do you think you can make a mini addon for Previous usernames too? That would be useful so users may notice the user's previous names anytime, just like this forum. http://forums.adventchildren.net/member.php?u=1

Help...My postbit_legacy

This seems to work even if you don't edit the postbit legacy. But...
And I get this error also...

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

You kinda alrady can do this (only the list of old names), but i forgot to add that to the documentation. Will see if i can add this to the documentation today.

PS That would basically just require you to create a new plugin with (almost) the same code as the Postbit plugin, and the same edits to the template.

When do you get this error, and what vB version are you using? Did you rebuild the bitfields as instructed? Are all files uploaded (in ASCII) correct?


Please be clear, does it work or not for you?

For some reason, (and I had posted something else before (sorry...but I am still fairly sure that the $ was missing from the db variable ;))

It created the history table without the table prefix as well...thought you'd care to know....


But I installed it anyway and it seems to work fine now :)

Thanks

Thanks for this, I somehow missed the table_prefix on that create statement. Fixed in my copy now, will update zip later today.

Could you please be more specific, i couldn't find a missing $ in the install code (or was it somewhere else?)

Then please click Install. :D

I did forget to clickinstall didn't I...whoops :p

all your db variables that you need to write changes to the database were missing their "$" in front of it

ie I changed:

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

to

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

and thats the only way it wrote to my tables...

Thank you sir.

There should be no $ in front of 'db', there is already 1 in front of vbulletin ($vbulletin->db->....)

Please disable the product, i will find what is causing this and uplaod an update.

Fix for the Private Message problem posted in Post #2. Thansk to mini2 for finding the problem and also providing a quick fix.

Turning off the legacy plugin fixed my problem too...

Found something else...

Fatal error: Call to a member function on a non-object in /public_html/forum/includes/class_dm_user.php(1719) : eval()'d code on line 5

when I tried editing via the profile link (changes it...no record to the database though) & when I made an edit to change it back from the AdminCP...same error

a) the .com part isn't included...i'm no expert...so exuse my ignorance when I say "why?" :p
b) class_dm_user.php wasn't in my install package

What vB version are you using?
Are you using table prefix?

New version 1.01 released:

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.

Yes, I have to agree as well that that is somewhat similar to what Ebay.com does and had suggested in my original request for this User Name Historty Plugin. It would be great to have it setup something like or exactly like what Aftermath showed us in that link to that users profile. I wouldnt want this feature in the forums, ONLY IN THEIR PROFILE. please keep the "hover effect" like MarcoH64 already has it.

Doug

thank you sir.

I actually never looked at ebay, and also didn't really read the suggestions made.

I will post a profile modification like suggested as an Addon Coding Example tomorrow.

This hack can now easily be used in other places by Addon developers, just a few lines of coding in a plugin needed.

So Is Everything Fixed in this hack now? Really want to install it.

Alright! Excellent Whoo Hoo! Yipee! :banana:

Thank you MarcoH64

Doug

Yes, all known bugs have been fixed, and some extra's added (mostly prepairing for future addons).

I have an issue. After I installed this:

Whenever i try and add a new group or edit an existing group's properties it runs Rebuild Bitfields in a loop.

Tell me that it has nothing to do with this hack so I can move on and explore other causes.

What version of vB?

Sounds like the same as what Andreas hack was suffering from first. Do you have Signature Limits installed?

Will do some testing.

Just tested adding a new usergroup to my testboard, and i have no problems running a clean vB3.5.1 with version 1.01 of this hack.

PS Can you change the usergroups, if you disable the Product and temporary remove the ./includes/xml/bitfield_mh_unm.xml

i love it ;] *installs*

Thanks, is there an option to display a page of who changed their names?

Hmm a recent changes list, sounds like a good idea. Expect an update tomorrow to make that possible. Where would you like to see that?

You can now only search in the AdminCP for names and see the list of changes.

I can't edit my postbit like Instructed but, it does work and the rebuild error I'm getting is caused by another hack. Thanks a million. Works perfect. I'm on version 3.5.

Without th edited postbit all will still work, you just don't see history in postbit.

PS Try with a fresh style, or revert your postbit (will remove all modifications) so you can start fresh.

Thanks Marco...

Wow Marco just what I've been looking for. Thank you a ton.

If possible, i'd like this to be a seperate page.

And is it also possible to allow certain people to change only one member (of their choice)'s username?

Marco...

It was the signature limits thingy...lol.

Funny thing is that it never reared it's head until i installed this..so i disabled it for now (The sig limits) until I can get it sorted.

Thanks.

I think Andreas already posted a fix in his hack thread.

Version 1.02 released:

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'

2 new Addon's are released:
Username Management Addon - History in Profile
Username Management Addon - Latest Username Changes on Forum

Clicks install.

Would adding value="$bbuserinfo[username]" to the Change Username fields have any adverse effect?

How, what, where, why?

Well to make the "Change Username" fields in the User CP appear more like the "Change Email Address" fields above it, I added the current username in the text boxes. I've not looked at the code or checked whether to see this hack will ignore updating the Username if it remains the same as the current one.

I guess I should stop being so lazy and actually look.. ;)

It will ignore it if not changed (i think). Since you will most likely not reuse your name, i thought it was useless to prefill with current.

PS Yes take a look, some parts (especially some of the caching in the functions) i am pretty satisfied with.

Why is the max days 255 days? I wanted to only allow members to change once a year max, but seems I cant, I put in 365 and save, but when i go back in, its set ast 255. ?????????

Hmmm that looks like a design error. To allow higher values, change the 'mh_unm_changelimit' column of the usergroup table in your database from TINYINT to SMALLINT. Will update this in the next release.

This may be useful for my forum..hm...I will test it out none-the-less. :)

I have no clue how to do that. Is there a query I can just run from the Admincp?

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

Yes, mh_unm_changelimit should be there twice.. :)

You can run the following 2 queries:

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

If you are using a table prefix, then add it in front of the tablename (ie. prefix_usergroup).

If you run the queries from the AdminCP, you must run 1 line at a time. If you are using something like phpMyAdmin, you can just copy&paste both lines in 1 go.

If you use SMALLINT(3), it will not increase the column size. ;)
SMALLINT defaults to 5 positions.

PS I never understand why people keep quoting numeric default values.

So if someone changes their member name, does it change the member name all all previous posts? Plus I can only assume that the old username will be in quoted posts...correct?

It will be changed everywhere, except quoted posts.
It uses the standard routines in vB to change the name, the same that is used when changing from AdminCP. Everything that would be changed when doing it from the AdminCP, is also changed with this hack.

It merely builds on top of the standard functions by giving Users and moderators also a place to change the name, and to add logging/reporting to it.

Nice update there...

feature request:

having this History of Usernames to be searchable as "registered users" so if someone wants to register with a username that is in this list, he will not be able to, and will be required to contact the admin if this is an error...

the situation come often when someone register, and not remember his password or complete username, and instead of asking for a new access he register twice... that came at least 3 times here this year only... ;)

something like "this username was once used by a user on this site. if you really need this username, please contact the admins. "... and this can be joined with the Ajax Alert...

Well that would be something completly different......and for 3 times a year?

But i have been thinking about not allowing a change if a name have been used before.

For example a popular guy on the board, decide to change his name, and a newbee immediate change his name the the popular guys old name.

A lot of people would get confused. Or maybe just no reuse of names for 3 month.

that's the same situation i guess, just not the same start.. lol

;)

Just installed this on my testboard and I really like it.
Thanks

Just one question:
What's wrong with semi-colons?

They are not allowed i guess. But that has nothing to do with my hack, it is vB itself blocking it.

Oh, ok, thanks for clearing me up.

I've got another problem:
When I allow a usergroup to change names, they can't login into the ModCP anymore.
They click on the "Change name" link, enter username and password in the login window, but instead of logging them in, the login window is displayed again.

Am I doing anything wrong?

edit: I just noticed that the user needs to mod at least one forum to make it work.
Is there a way to change this?

No there is no way to change that. Like written in the instructions, he/she needs to have modcp access, so Admin, S.Mod or Moderator (with a forum).

Ok, thanks.

And now, finally:
/me clicks install

With this installed with the Enhanced ACP Navigation plugin the Users category which is normally in the main AdminCP menu is now in the Custom Navigation menu lol..

Yes that is the big disadvantage of the Enhanced Navigation.

Hm... is it also possible for users [/i]not[/i] to see the name change history as well?

Who can view history is controlled by the usergroup settings.

Hi,

this is a wonderful hack and I want to use it but I have a feature request:

Is there a way to include an approval process?

A user can change his name but before this change becomes valid an Administrator has to approve it.
Some kind of moderated username change link in the AdminCP would be wonderful.

Would be nice to see this in v 1.0.3 :D

regards
jluerken

When I install your hack the USERS menu in the adminCP dissapears :-(

How can I change this?

Ok I change this.

Create a phrase called: mh_unm
Phrase Type: Control Panel Home Pages
Product: Username Management
Varname: mh_unm
Text: Username Management

Then edit cpnav_mh_unm.xml and delete all content.

Replace with:

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

Done!

If you have Andreas Hack installed the Users menu stays now on the main page and a new menu comes up on the second enhanced nav page.

Have fun...

Sounds like a good idea, might do it.
How can this happen? The menu is just controled by another file in your includes/xml. I didn't hear from anybody else having this problem.

Sounds to me that this is more a buck in Andreas hack then. It should be just nother option in the User menugroup (that is where it belongs).

And as you can see here: http://www.vbulletin.org/forum/showp...6&postcount=76
I solved it and posted a solution for all other users who might have it :D

Now I am waiting for version 1.0.3 with admin approval :-)

Thanks Marco,

Is it possible to include the option to change userid of any user, and only Staff members or super Admin could do this.

Please could you edit your solution to add a note that your solution is only if they have Andreas hack installed. Now it looks like everyone should be making that change.
No, i don't see the use of changing a userid. Since it will also require totally different coding, i son't see a reason to put it in this hack.

Any way to add tracking to when an admin changes the Username through the ACP? A few of my admin still go back to that old method instead of going to the ModCP to do it. Just to keep track of the name changes.

Even when an username is changed from ACP, it will show up in history i think.

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

Never really tried it, but i think it will follow the maximum set in your AdminCP for usernames.

Another alternative is to remove master="true", and it has the same effect.. ;)

However, just to re-iterate - you only need to do this if you have Andreas' "Enhanced ACP Navigation" plugin installed. Otherwise, this should work fine as it is.

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

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.

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.

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:

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

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.

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

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?

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.

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

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.

Like mini2 replied, all is controlled by Usergroups. Just setup a promotion to a new usergroup that will control access to the username change.

for some reason, even then I have it set to " can change own username" anyone who isn't a admin can't change their name? Any reason why?

What is the limit in days set to?

I'm having this problem as well, don't know what caused it, was working fine for about a month.

I have my limit set to once per day and users cannot change their name. If I set it the limit to "0" then they can.

I am not at home right now. Will have a look into it as soon as i am at home again (somewhere next week i hope).

I can find no reason why this could happen, can any of you 2 contact me in PM with url's and a test user to see it myself (+ temp admin access)

Did you implement that change?

Also, do you think it should work fine with ver. 3.5.3?

Thanks.

awesome, nice hack, glad I found this, this will be good for my premium members

Does anyone know how this works with photopost_vbagallery?

Usuailly. if you change a name on there via the acp you have to run a maintanence script to update the gallery information.

No, see the changelog for all already implemented changes
Yes it should work fine on 3.5.3