The Atlassian Community Forums are currently in read-only mode. We will be relaunching on a new platform on September 22 (read more here). We apologize for the extended downtime. For concerns or questions, please email communitymanagers@atlassian.com. See you on the other side, on the new Atlassian Community Forums! :)

×

Forums

Articles
Create
cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 

JIRA 6.0 has user keys, should we be using user keys in JQL instead of usernames in 6.0?

Robert Massaioli _Atlassian_
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 20, 2013

So JIRA 6.0 and the corresponding milestones are now avaliable and JIRA has added in a 'key' field to Users (as well as introducing a ApplicationUser class). However, I was wondering how this affects JQL. So, if I make the following JQL query:

reporter = <what goes here>

In the empty space do I put a 'username' or a 'user key'?

1 answer

1 accepted

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

1 vote
Answer accepted
Robert Massaioli _Atlassian_
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 20, 2013

The answer to this question (direct from the JIRA team) is: Nope - JQL will continue to use the username.

As I understand it, the gist of the change is that User keys are like id numbers: nobody should need to know what they are. End users of Atlassian products should only have to care about what they would call the user: which is the users 'username'.


This means that anything "user visible" will continue to use the users 'username' and never use the key. This includes JQL, User Pickers etc...

JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
February 20, 2013

The key is actually the same as the username, until the username changes. So are the Atlassian team saying that JQL won't work for users with changed usernames? I'm sure that's not the case...

mlassau_atlassian
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
February 21, 2013

The key is actually the same as the username, until the username changes. So are the Atlassian team saying that JQL won't work for users with changed usernames? I'm sure that's not the case...

The idea is that the userkey is never exposed to the end-user, in the same way that we try not to expose (for example) the Version ID.

If you write JQL like "assignee = jamie", save this as a filter and then rename that user to "jechlin", then the filter will no longer work. (You would need to change it to "assignee = jechlin")

This is consistent with general JQL behaviour, because JQL mostly uses display names that can be changed over time.
e.g. "fixVersion = '3.0' and project = 'iFoo System' and assignee=jechlin@example.com"
would break if you change the name of the version, or the project, or the user's email address.

ConradR
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
February 21, 2013

I think searching for userkey should be possible to make sure your filters won't break. For versions this is possible and a best practise:

It is safer to search by version ID than by version name

JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
February 21, 2013

OK, that makes sense Mark. I don't think it's entirely the same though because a version ID is an inscrutable Long, whereas a user key looks identical to a user name. But again, my example of JQL is not a good one because as you say, other JQL clauses break if you change the display name of the thing you're querying on.