Insight User Import synchronizes and maps inactive Jira user to User object
Platform Notice: Data Center - This article applies to Atlassian products on the Data Center platform.
Note that this knowledge base article was created for the Data Center version of the product. Data Center knowledge base articles for non-Data Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
After synchronizing User Import, inactive Jira users get mapped to a User object attribute, despite "Include inactive users" option being set to false in User Import configuration.
Environment
- Jira 8.x + Insight 8.x version
- Environment previously upgraded from Jira 7.x
Diagnosis
- Object contains an attribute of type "User":
- User Import is configured, "Username" data locator mapped to attribute type "User":
- "Include inactive users" parameter in the User Import configuration set to "false"
- The affected user had been originally renamed and deactivated. Then, a user with the same original name was created. Example: user "johndoe" had been renamed to "johndoe.test", and then got deactivated. Later, a new user "johndoe" got created.
To verify if this was the case, execute the following SQL query for the user in question (replace "johndoe" with the actual affected user name):
select * from app_user where user_key = 'johndoe' or lower_user_name = 'johndoe';
The result for the affected user should be as follows: the record with lower_user_name = 'johndoe.test' corresponds to a user that had been created and renamed later in Jira 7, a user with lower_user_name = 'johndoe' is a user that later got created in Jira 8.x.
id | user_key | lower_user_name ------+---------------+----------------- 11200 | JIRAUSER11200 | johndoe 11201 | johndoe | johndoe.test
Cause
When Insight User import is running, the user lookup will try to match the data locator value to "user_key" column in "app_user" table first, and if it doesn't get a match, it will fall back to "lower_user_name" column value.
In this case, when "Username" data locator is mapped to User attribute type, the "user_key" will actually contain the matching value (equal to value in "Username" data locator) for the original inactive user. Hence, wrong user will be matched and selected.
Solution
- In the Object mapping configuration, map the "User Key" data locator to the attribute type "User"
- Synchronize the import again
- Delete old, invalid objects where inactive users were incorrectly mapped.