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

[Andy Heinzer · Accepted solution]

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.

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

[Andy Heinzer]

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.

Andy

[Oleksii Skachkov]

Hi, @Andy Heinzer ,

I have a dropdown list (singleselect) with userName. When I try to get the user, I get only the username "test". I need to get userKey like JIRAUSER00001 to use it in my logic.

how I can get userKey by userName without using ComponentAccessor?

[Andy Heinzer]

Hi @Oleksii Skachkov 

I'm not sure I fully understand your ask here.  Custom fields in Jira will only return the username itself when queried directly.  I believe you would have to lookup that username in order to figure out what the user_key value is.  This is something that could be done in a REST API call to the endpoint GET /rest/api/2/user.  That endpoint can be queried either by username or by key.  You would just need to specify which parameter you are searching by here.

The custom field like a select list won't let you search by user_key if I recall correctly here.  Does this help?

Andy

[Oleksii Skachkov]

Hi @Andy Heinzer 

I solved my problem: using jQuery like 

mySingleselect.getSelectedDescriptor().properties.userKey;

In original task, I have to get userKey from singleselect field and send it to the backend.  And problem was: how to get this userKey?

Hope it helps somebody )

[Keith]

Thank you, Andy!

[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:

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

Regards