You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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
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.
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.