|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Jeff Turner [Atlassian] - 17/Sep/04 02:43 AM
A workaround for this limitation is as follows:
One thing that is related to this is that you use the username as the foreign key to identify users (e.g. jbloggs) rather than the id (integer) from the userbase table.
I have written a script to migrate users by updating all the tables. Even if you didn't want to rename users (something that is even more important when using external authentication and don't have control over usernames) I would argue that it is worth fixing the schema. It isn't denormalised since you still need to do a join to get the user's "Full Name" for display purposes so this schema also means you take up a lot more space in the database without any performance benefit. Robert,
The schema is partially denormalized like this to handle external 'userbases' like LDAP, where the profile is stored outside the database, but the preferences are store in the JIRA database. Since there is potentially no ID to reference with a foreign key, we use the username instead. Some questions relating to the LDAP comment:
1) What proportion of your client base hooks some other directory into JIRA as opposed to using JIRA's inbuilt one? 2) What sort of "LDAP userbases" don't have IDs, or don't have the flexibility to modify their schemas so that they do? 3) Even if this does happen, how common is it compared to someone getting married and changing their name? 4) Or someone spelling a user's name wrong when they were first created, but not finding out until after they have done some work? Adam,
> 1) What proportion of your client base hooks some other directory into JIRA as opposed to using JIRA's inbuilt one? A 'significant minority'. > 2) What sort of "LDAP userbases" don't have IDs, or don't have the flexibility to modify their schemas so that they do? I'm not sure you've understood the issue here - whether LDAP directories have IDs is irrelevant. It's simply a matter of prioritisation vs. the other popular issues: Hi Everyone,
I'm just cleaning up this duplicate issue, and resolving it. So for those who have voted or are watching this issue, this issue is now being tracked at JRA-1549 Thanks, Respectfully, Jeff, I think I understand the issue completely, and YOUR response seems to be missing the gist of the issue and the subsequent discussion.
I was asking questions specifically directed at your justification (which I do not think is really very good, to be honest) of why you've done the user schema the way you have. Nowhere against this issue has anyone mentioned anything about priorities until you piped up with your somewhat non-sequitur response to my last three questions. Adam,
I have added a comment to JRA-1549 regarding this improvement. We see that this issue is important - Jeff was trying to say that the most difficult thing we have to do is prioritise between improvements. Thanks, |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Major
Rename users
