Howdy Y'all,
The first big concern here is that this Knowledge Base (KB) article was written for a very specific unsupported use case, that was a "use at your own risk" scenario that applied to certain version ranges of Jira. Despite all the warnings on the KB noting the dangers many users that followed the article used it as though it was official supporting documentation for any version and would effectively completely wreck their databases and require a lot of downtime in attempts to fix the issues that the article would lead users into due to complexities and variations of individual setups that a general guide simply could not cover effectively enough.
This article was removed as it was deemed too dangerous to attempt due to the ever-increasing number of variables in the user management system. Primarily the Jira data model is sufficiently complex that these steps were too simple and would leave unknown problems that would be discovered later on. A secondary problem is this article is getting used in many cases that can be solved by more simple means, such as Jira features like reassigning issues to a new user or renaming a user.
The kb article itself assumed there’s a known end state Jira’s data should be in when performing a merge operation. This actually isn’t defined anywhere and has many different variables depending on add-on apps and customizations as well as variations between Jira versions, the different license tiers, and the Jira flavors (Software/work management/service management/roadmaps/align etc...) so this would be needed for every possible variable prior to trying to write any sort of fix either inside the application code or by directly modifying the data. Basically every attempt to follow the article leads to too many edge cases to consider and everyone’s merge needs are going to be slightly different based on their scenario therefore as the article was too generally defined requiring too much interpretation with a high potential for data loss if a variable was encountered the article was removed.
The best outcome here is to push to use existing features in Jira to achieve this goal, or push to incorporate features like https://jira.atlassian.com/browse/JRASERVER-3132 by voting for and commenting on the feature requests to help influence a bump in priority for the product teams attention by highlighting your use case and impact of the features.
And instead of the deprecated KB, we recommend renaming the users to their new usernames in the existing LDAP/AD directory, performing directory sync in Jira, then adding the second directory to Jira as covered in Migrate to LDAP directory using different username formats for Jira server. This will effectively preserve content ownership and permissions for each user in the new LDAP/AD directory.
Regards,
Earl
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.