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.
For JSM June Challenge #2, share how your non-technical teams like HR, legal, marketing, finance, and beyond started using Jira Service Management! Tell us: Did they ask to start using it or...
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