Jan 20, 2003, 3:08 PM
Administrator (9387 posts)
Jan 20, 2003, 3:08 PM
Post #2 of 7
Views: 4646
Hi,
No, not currently (but they can still change their Gossamer Forum name). We need to update Links SQL to make this possible.
Cheers,
Alex
--
Gossamer Threads Inc.
No, not currently (but they can still change their Gossamer Forum name). We need to update Links SQL to make this possible.
Cheers,
Alex
--
Gossamer Threads Inc.
Jan 21, 2003, 2:45 AM
Veteran (2199 posts)
Jan 21, 2003, 2:45 AM
Post #3 of 7
Views: 4630
Will this be implemented?
The reason why I am asking is that I have users that I imported from Links 2 to Links SQL, so their email address became their username. I wrote a plugin for Links that those users with an email address as their username have to change their username when they log in. And they can change their username anytime.
So, I think it might be useful to be able to change the username.
Ivan
-----
Iyengar Yoga Resources / GT Plugins
The reason why I am asking is that I have users that I imported from Links 2 to Links SQL, so their email address became their username. I wrote a plugin for Links that those users with an email address as their username have to change their username when they log in. And they can change their username anytime.
So, I think it might be useful to be able to change the username.
Ivan
-----
Iyengar Yoga Resources / GT Plugins
Mar 24, 2006, 2:59 AM
User (497 posts)
Mar 24, 2006, 2:59 AM
Post #4 of 7
Views: 4286
So...this still isn't resolved? I also need option for user to change their username in Community. Also because reason Yogi told.
Any help? (I've tried change username through GLinks Administration but when I change it their, community database don't recognize that).
Regards.
UnReal Network
Any help? (I've tried change username through GLinks Administration but when I change it their, community database don't recognize that).
Regards.
UnReal Network
Mar 27, 2006, 8:31 AM
Administrator (9387 posts)
Mar 27, 2006, 8:31 AM
Post #5 of 7
Views: 4284
Hi,
No, this isn't yet implemented, primairly due to how Links handles usernames. If it's for one or two users, you could try and do it manually by changing it in Links and also in Community using SQL, but be careful as that can break things.
Cheers,
Alex
--
Gossamer Threads Inc.
No, this isn't yet implemented, primairly due to how Links handles usernames. If it's for one or two users, you could try and do it manually by changing it in Links and also in Community using SQL, but be careful as that can break things.
Cheers,
Alex
--
Gossamer Threads Inc.
Mar 30, 2006, 10:54 PM
User (497 posts)
Mar 30, 2006, 10:54 PM
Post #6 of 7
Views: 4270
Ok. Thanks.
Problem is that this isn't just user or two but few hundreds (after changing from Links 2.0 to LinksSQL).
Will wait for the time that this maybe will be implemented.
UnReal Network
Problem is that this isn't just user or two but few hundreds (after changing from Links 2.0 to LinksSQL).
Will wait for the time that this maybe will be implemented.
UnReal Network
Mar 31, 2006, 10:53 PM
Veteran (6956 posts)
Mar 31, 2006, 10:53 PM
Post #7 of 7
Views: 4265
I've been looking at this exact issue, but it will require some central planning from GT.
I wanted to sync up GForum, and GLinks, so that I could start pulling my plugins through the community system, and so that users would have the abilities to change their names, without breaking the more complex relationships based on their unique ID.
Right now, the Links USERS table does not use an auto-increment field like the rest of the program. What that means, is that you *can't* change the user name, without breaking a *lot* rules, and physical linking in the program. Changing the primary key value of a record *should* change that record (eg: it should really be deleted and reinserted). It has to do with what a primary key is, conceptually, and what other parts of the program and addons expect that key to do.
On an active system, doing it manually might even break something depending on how it was done, and what was going on at the time. Mucking with primary keys that have many fk_ relations to other parts of the program, can be a prescription for disaster. On a basic GLinks system, it might not be much, but if you have customizations, other plugins, and such, it might mess things up a lot.
It would be a "simple" change if GT undertook implementing it, so that numerous quirks could be handled in an organized fashion.
*BUT*
Structurally, it would mean changing the "Username" and/or "LinkOwner" fields to FK to the users table on the auto-increment field, which would not change no matter how many times the user changed their name.
Any plugins or other tables that used an fk_ relation or stored the Username in the table would have to be rewritten to use the User_ID
I can see this being phased in, over the next few releases, but it would probably prompt a new major release to fix this, or change this, behavior.
The real problem will come from the fact that many routines expect the Username to be the primary key, but an autoincrement field wants to be primary/unique, and a table can only have one primary key.
As I've said, I looked into this, then changed my mind for now <G>
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
I wanted to sync up GForum, and GLinks, so that I could start pulling my plugins through the community system, and so that users would have the abilities to change their names, without breaking the more complex relationships based on their unique ID.
Right now, the Links USERS table does not use an auto-increment field like the rest of the program. What that means, is that you *can't* change the user name, without breaking a *lot* rules, and physical linking in the program. Changing the primary key value of a record *should* change that record (eg: it should really be deleted and reinserted). It has to do with what a primary key is, conceptually, and what other parts of the program and addons expect that key to do.
On an active system, doing it manually might even break something depending on how it was done, and what was going on at the time. Mucking with primary keys that have many fk_ relations to other parts of the program, can be a prescription for disaster. On a basic GLinks system, it might not be much, but if you have customizations, other plugins, and such, it might mess things up a lot.
It would be a "simple" change if GT undertook implementing it, so that numerous quirks could be handled in an organized fashion.
*BUT*
Structurally, it would mean changing the "Username" and/or "LinkOwner" fields to FK to the users table on the auto-increment field, which would not change no matter how many times the user changed their name.
Any plugins or other tables that used an fk_ relation or stored the Username in the table would have to be rewritten to use the User_ID
I can see this being phased in, over the next few releases, but it would probably prompt a new major release to fix this, or change this, behavior.
The real problem will come from the fact that many routines expect the Username to be the primary key, but an autoincrement field wants to be primary/unique, and a table can only have one primary key.
As I've said, I looked into this, then changed my mind for now <G>
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.