Question on user comparisons with JIRA 6+

[William Crighton _CCC_]

Since users are now 'identified' by their 'id' value instead of their login name is this statement still a valid one to use when trying to determine if two users are the same account?

if(reporter.getName().equals(currentUser.getName()))
{
    // do something
}

or do we need to reference the com.atlassian.crowd.embedded.api.User id attribute and compare with that?

If the answer to the above is 'Yes' do we need to go and refactor every user comparison we've written to reference the new id value?

Thanks.

[Jobin Kuruvilla [Adaptavist] · Accepted solution]

As far as I understand, you should still be able to do this because usernames will continue to be unique. It is just that the name might be changed in future as renaming is allowed. But that should be fine for you as both reporter and current user name will change if the renaming is done.

[William Crighton _CCC_]

Jobin,

Thank you very much for your reply. I'm considering it at the moment and will accept it if I can't think of an edge case where that doesn't hold. However, I'm skeptical that I'll think of such a thing.

-wc

[William Crighton _CCC_]

{major edit here}

William Crighton [CCC] ·

YUK! I totally mis-understood your question. Rereading it now I believe you are asking where I sourced the information that you quoted...that is:

Since users are now 'identified' by their 'id' value instead of their login name

That information came from this Atlassian Doc page:

https://developer.atlassian.com/display/JIRADEV/Renamable+Users+in+JIRA+6.0

Specifically - and going through this exercise illuminates why you asked your question - Atlassian is calling it a 'key', not an 'id'...my bad:

We have introduced a new field called "key" to users that is a case-sensitive String and will never change (also referred to as the "userkey").
In order to correctly support systems with multiple directories, this key is applicable at the application level, not at the user directory level.

Existing users will get allocated a key that is equal to the lowercase of the username.
This means there is no need to migrate existing data: the stored value is the user key and even if the user's username is later edited, this stored key will remain correct.
(This assumes that you are already lower-casing the stored usernames which was required in order to avoid case-sensitivity bugs).

When to use the key, when to use the username

The userkey should be considered the primary key of the user.
Anytime you want to store a reference to a user in long term storage (eg the DB or Lucene index) you should use the key because it can never change.

However, the userkey should never be exposed to the end user; only the username should be displayed.
The username is a unique secondary key, but should not be stored in long-term storage because it can change over time.

{end}

{original dumbass answer...}

I don't understand the question...are you asking where the 4 lines of code came from? If so I just plucked them from the ether surrounding a discussion I had with a coworker on JIRA 6 changes. More formally, I guess, the code would look like this:

.....

{end}

[Timothy]

Since users are now 'identified' by their 'id' value instead of their login name

Where did you source this from?

[William Crighton _CCC_]

YUK! I totally mis-understood your question. Rereading it now I believe you are asking where I sourced the information that you quoted...that is:

Since users are now 'identified' by their 'id' value instead of their login name

That information came from this Atlassian Doc page:

https://developer.atlassian.com/display/JIRADEV/Renamable+Users+in+JIRA+6.0

Specifically - and going through this exercise illuminates why you asked your question - Atlassian is calling it a 'key', not an 'id'...my bad:

We have introduced a new field called "key" to users that is a case-sensitive String and will never change (also referred to as the "userkey").
In order to correctly support systems with multiple directories, this key is applicable at the application level, not at the user directory level.

Existing users will get allocated a key that is equal to the lowercase of the username.
This means there is no need to migrate existing data: the stored value is the user key and even if the user's username is later edited, this stored key will remain correct.
(This assumes that you are already lower-casing the stored usernames which was required in order to avoid case-sensitivity bugs).

When to use the key, when to use the username

The userkey should be considered the primary key of the user.
Anytime you want to store a reference to a user in long term storage (eg the DB or Lucene index) you should use the key because it can never change.

However, the userkey should never be exposed to the end user; only the username should be displayed.
The username is a unique secondary key, but should not be stored in long-term storage because it can change over time.