Your Account -- nsngroups issue when changing username

Posted: Fri Jan 30, 2009 9:43 am

I don't think this issue is specific to 2.3 ... it has probably been a a problem as long as nsngroups has been integrated with *Nuke. But we discovered it in testing for 2.3 and won't be able to fix it until 2.4 time so I thought I'd post the "work-around" here.

Basically, RNYA (and I believe previous versions of YA though I have not verified this) allow you to change the username of a registered user. There is a stupid warning about "do this at your own risk" (what the heck is that supposed to mean???) but you can go ahead and change the username. So, you had abcdefg as a username and now you make it hijklmn.

Now you have some nsngroups with abcdefg as a member. After you change the username abcdefg will still be left as a member of those groups and they won't know anything about hijklmn. The workaround is that you have to go into groups administration and delete the old username and re-add them under the new username.

As I said, we will try to resolve this for 2.4 but that's quite a ways out in time. The core issue is that nsngroups stores the username where it really shouldn't ... it should store the uid only and look up the username when it needs it. But changing that is going to take some work and a lot of testing.

For now, if you change a username take a look at your groups afterwards and make any adjustments required.

Posted: Fri Jan 30, 2009 11:31 am

Thanks !

It is just not recommended to allow username changes because of such confusion in my opinion. Therefore the settings to allow to change the username in the forums administration should always be : No.

Posted: Fri Jan 30, 2009 11:43 am

I see no settings in RNYA that would stop an admin from changing a username. I don't see it in Forums either and I don't think any setting in forums would have any effect on RNYA. Correct me if I'm wrong and post where to make the settings change.

Personally, while I wouldn't make massive username changes in a willy-nilly fashion there are situations where it makes sense. With the workaround that I've posted, the effects can be mitigated.

Posted: Fri Jan 30, 2009 11:57 am

Susann is refering to the option to allow users to change their own name.

Posted: Fri Jan 30, 2009 12:18 pm

Sorry, I must just be missing it -- where is that option set?

Posted: Fri Jan 30, 2009 1:03 pm

It is in the forum admin under General Admin -> Configuration

Posted: Fri Jan 30, 2009 1:09 pm

Forums configuration.
I have had no user within 4 years which need to change his name.
I´m general not willing to allow exceptions. This is the way to avoid issues in Nuke and was a recommendation since years since Nuke plus forums integration was available.

So its somewhere clear you need to adjust some things if you really change a username and therefore is this warning:

"do this at your own risk"

Posted: Mon Feb 02, 2009 9:20 am

Thanks Jakec and Susann. However, my point is that the setting in Forums configuration has NO EFFECT on whether you can change a username in RNYA. In fact, as far as I can tell it has NO EFFECT whatsover since we don't do user administration through Forums at all. And there is no way through RNYA to prevent a user name change -- at least not that I know of. You can make it an administrative practice on your site not to change user names and that is all fine. But any admin who has access to YA administration can ignore the practice and change the names and you will wind up with inconsistency if the user is in a nsngroup. And that is all that this thread was really intended to address ... to give a warning about this and tell people to check their nsngroups if they change any usernames.

Systematically this problem should really be addressed for 2.4 -- it can't be addressed adequately in 2.3.01.

Posted: Mon Feb 02, 2009 9:27 am

I totally agree. Very Happy

Site Admin Joined: Jun 04, 2004 Posts: 6433

How important is this change? I mean, there are quite a few enhancements that would give much more value, IMO. I have to agree with Susann... How many times do you change user names? The user chooses his/her user name to start with.

Posted: Mon Feb 02, 2009 11:00 am

I guess I distinguish between an enhancement and a bug fix and put the two into separate categories. This is a bug fix. A system should not let you make changes which result in a loss of "relational integrity". Sorry but I am old school there. If we want to change RNYA so that it doesn't allow a user name change that would be okay. But if we permit it then we should do it right. Leaving a different username in nsngroups from that in the users table after a username change is a bug. The fact that we post a vague warning on the page doesn't mitigate that fact. The fact that, as a matter of practice, people don't run into the bug that often may mitigate it a little but it is still a bug.

One of the reasons we have put this off until 2.4 is because we need to look more closely at the underlying issues. Really nsngroups should not store the username in its table I think. The UID is the primary key of the users table and should also be the only key data kept in the nsngroups table. Then nsngroups should look up the username from the users table every time. That is what relational design is all about -- you don't change primary keys and you don't store redundant data all over the place. (I'm simplifying and I know that *nuke is not really a relational design with well thought out primary and foreign keys and the like, but some of the principles do (or should) apply).

In terms of enhancements, I think there is consensus that we need to update nsngroups and this fix could and should be part of that larger effort.

Posted: Mon Feb 02, 2009 11:36 am

I agree with fkelly. Short of adding new features and redesigning the layout of nsn groups I believe this to be an easy fix.

Posted: Mon Feb 02, 2009 12:28 pm

I don't disagree. I'm just saying that it's not that important (which is probably why it hasn't been "fixed" before - similar to the issues with deleting users). It's fine to note this and fix it, but there are bigger fish to fry. Isn't the Pareto Principle (enunciated by Joseph Juran circa 1941) old school, too? Smile

And regarding relational integrity...did anyone not remember that groups are defined in 2 tables, and group members are defined in 2 tables? Again, bigger fish to fry...

BTW, nuke_nsngr_groups (muid), nuke_nsngr_users (uid), nuke_bbgroups (group_moderator), and nuke_bbuser_group (user_id) all have the primary key from the user table (user_id). The question really is: why does nuke_nsngr_users also have the user name (uname) field?

A quick scan of the source indicates that it's only used for sorting purposes on the lists displayed when maintaining group users and viewing users to expire / have expired. This could be accomplished with a simple join to the user's table (without much effort, since it already uses the user ID, not the user name), eliminating the need for this extra field (and the associated maintenance overhead) in the nuke_nsngr_users table.

Affected files:
admin/modules/nsngroups/NSNGroupsUsersAdd.php - listing users by name
admin/modules/nsngroups/NSNGroupsUsersAddSave.php - inserting
admin/modules/nsngroups/NSNGroupsUsersExpire.php - listing users by name
admin/modules/nsngroups/NSNGroupsUsersMove.php - listing users by name
admin/modules/nsngroups/NSNGroupsUsersUpdate.php - listing users by name
admin/modules/nsngroups/NSNGroupsUsersView.php - listing users by name
modules/Groups/public/GRJoin.php (only an insert here)
INSTALLATION/rn_dbupgrade.php (creating table and adding index)
INSTALLATION/setup.php (when creating the table and updating group records)
INSTALLATION/sql/includedInCore/rn_nsngroups.sql (creating the table)
INSTALLATION/sql/rn_core.sql (creating the table)

Have fun...