Database; wrong user_key in app_user table

[Deleted user]

Hello there,

if you create a user in Jira Core, it updates the table app_user in the database (New Inserts: id, user_key and lower_user_name).

The problem is, that sometimes the user_key is "JiraUserX" (X for a number) and sometimes it's the same as the lower_user_name.

My question is why and how to change it.

best regards,

it-frastanz

[Nic Brough -Adaptavist-]

I'll take a slightly different approach to - why do you want to change this?   What problem is it causing you?

[Deleted user]

For analysis and it causes an incorrect database!

[Nic Brough -Adaptavist-]

"for analysis" tells us nothing about why you want to change it, or what problem it us causing.

Could you tell us what is going wrong in your "analysis" that is caused by this?  Or more usefully, why your "analysis" is struggling with it?

[Cory Burns]

I am looking into something similar I have about 700 users in an active system. Out of those 700 about 30 have their key as JIRAUSERXXXXX. We are doing a custom API import into Project Team addon from a specific data source. That datasource has the username (first part of their email). 670 users have this value as there userkey. This allows for the API to import the user info.

What happens I get an error in the JSON payload the user does not exist (which from the technical stand point is true, that USERKEY does not exist the user name and account does.  Using the constant value in the datasource , this allows us to merge the specific information from the datasource in Project Teams, without having to create a custom hash table or custom API calls specifically for 30 some odd users and any future user.

The users email address even if their name changes will not change. So the username even if the users name changes will not change. We already have consistent value, in LDAP, Workday, Oracle, etc. JIRA is the only one that once we upgrade to 8 has replaced "username"  @email.com, with JIRAUSERXXXXX. So my function is not anything other than to write the least amount of calls to JIRA to update the API on the fly each time. If it is the only system that in not constant with all others. 

I have already disabled the function for future users to use JIRAUSERXXXX in darkmode. I just need to fix the handful of users that remain

[Daniel Ebers]

The observed behaviour is part of "GDPR changes in Jira" (further reference is available from here: https://confluence.atlassian.com/jiracore/gdpr-changes-in-jira-975041009.html)

I strongly assume the 30 users which already have JIRAUSERXXXXX are new ones - they must have been created after an upgrade taking place to a version later than Jira 8.2.

You said you disabled the behaviour already using dark features - ok.

Although I am not aware of any (neither hacky nor safe) way to fix the 30 "anonymized" user keys back to the old standard.

[May Srichainont]

Hi Cory, you said you have already disabled the function for future users to use JIRAUSERXXXX in darkmode.  Can you tell me how you disabled it, what is the function name?   Does it mean that after you disable this feature in darkmode, everything will go back to the way that it was before the the later than Jira 8.2 upgrade?  Thank you.