It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Generating user keys in Jira 8, How it works with AD sync


According to this article Generating user keys new users created in Jira should get key with new naming convention and it shouldn't be equal to username...

I've checked in my test instance and it is still name==key. 

Do I need to turn on this GDPR changes in Jira somehow?

How it is related to accounts synchronized with AD, I don't see any setting that determine which AD parameters goes to key value in Jira so I guess in not adjustable?




1 answer

1 accepted

0 votes
Answer accepted
Andy_Heinzer Atlassian Team Oct 09, 2019

Hi Lukaz,

I see that you are looking to better understand the user key values that Jira server will use when user accounts are created.  That link you cited was specifically posted for documentation space called 'preparing for Jira 8.2'. 

In that page it explains that the default behavior in Jira 8.3 and before is to use the username as the userkey.  It goes on to explain that in older versions of Jira you can enable a dark feature so that when accounts are first created, they can use this new user_key naming convention:

Testing the change

This change is hidden behind a dark feature flag. To enable it:

  1. Go to <Jira_URL>/secure/SiteDarkFeatures!default .jspa 
  2. Add the com.atlassian.jira.user.dbIdBasedKeyGenerationStrategy.enabled flag.

We will enable this new behavior by default in upcoming releases. The dark feature is there to give you a head-start, a way to check and prepare your apps.

Just understand that if you enable this dark feature in Jira 8.3.x or before, it won't affect any user accounts that already exist in Jira.  It will only change the user key convention used for any newly created accounts.

This change has been implemented by default in Jira, but this only started as default since 8.4.  You can see this change in the ticket JRASERVER-69842.

I hope this helps to explain the different behavior between versions in Jira.


Thank you Andy,
But actually, I have jira 8.4 and for newly created users, still name =key
so I created user and run:

Maybe I check something in wrong way???

Andy_Heinzer Atlassian Team Oct 11, 2019

I'm not sure if your method is wrong exactly.  But perhaps it is pulling back unexpected user account records.  I could see a scenario where your query could be pulling back a username from an unexpected user directory. If you have multiple user directories in Jira and they contain the same username, it's possible your method could be pulling back data of accounts that exist in different user directories.

I tend to query the SQL database directly in cases like this. I am not used to checking in the manner you described there, but I take it you are using scriptrunner (or an alike) to query the Java API for this info.  I installed scritprunner, and copied your script there in my Jira 8.4.1 site.  I got back the expected user key there.

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.user.util.UserManager

UserManager userManager=ComponentAccessor.getUserManager()
def user = userManager.getUserByName("admin").properties

My results were as follows:

[active:true, class:class com.atlassian.jira.user.DelegatingApplicationUser, id:10000, key:JIRAUSER10000, directoryId:1, directoryUser:admin:1, emailAddress:admin@localhost, username:admin, name:admin, displayName:admin]

This was the first account I created on the install, so it has the key of JIRAUSER10000, note it has a directoryid of 1.  But I also then connected an LDAP directory (directoryid of 10000) and synced over another user, here is that result for that specific user as well:

[active:true, class:class com.atlassian.jira.user.DelegatingApplicationUser, id:10100, key:JIRAUSER10100, directoryId:10000, directoryUser:Java Duke:10000, emailAddress:, username:Java Duke, name:Java Duke, displayName:duke]

In both cases, I can see the accounts have the expected user key does not match the username at all.  Which is what I would expect in a Jira 8.4, or an older version that has the dark feature of com.atlassian.jira.user.dbIdBasedKeyGenerationStrategy.enabled in the site wide dark features section.

I would be interested to see if perhaps you can run a SQL query against the Jira database to see what you get back.  For example, try running:

select au.user_key, cu.* from cwd_user cu 
JOIN app_user au ON au.lower_user_name = cu.lower_user_name;

It should return to you a list of all the users in Jira with their user keys and their directory_id values too.


So I'm not sure what is different here with your environment.  If the steps above do not help to clarify the problem here, then the first thing I would think would be that if the user account existed in Jira before Jira was upgraded, Jira is not expected to change the user key.   But even if you did only create this account after installing Jira 8.4, or say your Jira 8.4 is a fresh installation, my concern now would then still be to learn if perhaps you might have some other related dark feature enabled that might be preventing this change.  You could check for this by going to the dark features page /secure/SiteDarkFeatures!default.jspa

If you happen to have the opposite feature flag here


Then this would flip back a Jira 8.4 to use the old method of creating user keys.

If that is not the case here, then I would like to know more about your environment.  Was this an upgrade of Jira?  Or a fresh install?  If this is an upgrade we might want to consider the possibility that the upgrade potentially did not complete all upgradetasks.  If this happened, we should be able to tell by taking a closer look at the $JIRAHOME/log/atlassian-jira.log file when Jira starts up. 

I hope this helps.


Hi Andy,

So You are right, in DB value is, in my case Username: u47592 and User_Key: JIRAUSER43863.

But in such case, what this method is doing? because I expect that if I run it like that:


import com.atlassian.jira.component.ComponentAccessor

import com.atlassian.jira.user.util.UserManager


UserManager userManager=ComponentAccessor.getUserManager()


def user = userManager.getUserByName("u47592").getKey()

It should return JIRAUSER43863 but what I actually receive is u47592.


Is this a bug in getKey() method?


Best Regards,


Andy_Heinzer Atlassian Team Oct 21, 2019

Hi Lukasz,

The method you refer to is designed to let you input a username, and get back the user_key value.  I believe that is what it is doing here.  I'm not confident this is a bug though yet. I mean it could be, but I can't recreate the problem you have described so far and I do not feel that I know enough about your environment to understand the results you see here so far.  From that description of that method:

Returns the key which distinguishes the ApplicationUser as unique. The same key is shared by all Users with the same username (ignoring case) across all user directories.

So I would be interested to learn what you get back from the following SQL queries in that environment:

select * from app_user where lower_user_name='u47592';

select * from cwd_user where lower_user_name='u47592';

Having multiple returned values from the cwd_user table could be expected if you have multiple user directories where that username exists, but I'd be interested to see what exists in the app_user table for this query as well.  It should only have a single entry and if it has the same user_key as username, then it seems likely the account was originally created in Jira before the change to user_key naming convention (JIRAUSER00001 and so on).

I hope this helps.


Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you