nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Julius Bär

Hello,

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?

BR,

Lukasz

Accepted answers

Andy Heinzer

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:

Go to <Jira_URL>/secure/SiteDarkFeatures!default .jspa

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.

Andy

All comments

Andy Heinzer

Hi Lukaz,

Testing the change

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

Go to <Jira_URL>/secure/SiteDarkFeatures!default .jspa

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.

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.

Andy

Julius Bär

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

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

com.atlassian.jira.user.dbIdBasedKeyGenerationStrategy.disabled

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.

Andy

Julius Bär

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,

Łukasz

Hailin Zhang

Our jira is having issue with this strange anonymous access setting.

app_user.user_key will be put as value of User Picke custom field instead of cwd_user.user_name. This causes issue on jira reports and customfield values.

Found a way to disable this:

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

Regards

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

jira-server