• 29
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Atlassian Status as of 31 October 2013

      Hi everyone,

      Thank you for your votes and comments on this feature request. Whilst this is something we would like to implement some day, it is not planned to be a part of a forthcoming release.

      We will be focussing on improving the integration of Crowd within our Atlassian suite of products, as well as simplifying and improving the overall user management and a unified administrative experience.

      If our release plan changes and this feature request becomes a priority, this ticket will be updated. If you'd like to better understand how we make roadmap decisions, have a read of : https://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+Policy

      Cheers, Helen Hung
      Atlassian Product Management

      I would like to move users from one directory to another one. The target scenario in our case would be creating an archive directory that contains users that are not longer required (and should not only be inactive).

            [CWD-747] Moving users between directories

            April added a comment -

            You know, I don't see much for SQL on the documentation site, but I think the dev documentation will cover what you need: https://developer.atlassian.com/server/crowd/database-schema-and-example-sql-for-crowd/

            That's what I used.

            Our implementation is very simple and does not use nested groups, so all I do is get the source directory ID:

            // MSSQL
            select * from cwd_directory
            

            Then I grab the users, which I usually tag with a temporary group:

            // MSSQL
            select * from cwd_user where directory_id = '####' -- Source directory ID
            and lower_user_name in (
            select child_name from cwd_membership where parent_name = 'AccountsToMove')
            order by lower_user_name
            

            Then I grab the users' memberships:

            // MSSQL
            select parent_name,child_name from cwd_membership where directory_id = '####'
            and child_name in(
            select lower_child_name from cwd_membership where parent_name = 'AccountsToMove')
            Order by child_name,parent_name
            

            Then I use these files for the CSV import to the new directory.

            NOTE: even though you're using delegated LDAP, you'll still need to have a password column. Doesn't matter what text you put in there, as Crowd will execute an AD lookup at the moment of logon and update this value as expected, so it's just a placeholder.

            Once the users have synced down to the client apps, then I delete them from the source directory and send out the 'migration complete' mail.

            So far for us, this has all been very safe and easy to do.

            April added a comment - You know, I don't see much for SQL on the documentation site, but I think the dev documentation will cover what you need:  https://developer.atlassian.com/server/crowd/database-schema-and-example-sql-for-crowd/ That's what I used. Our implementation is very simple and does not use nested groups, so all I do is get the source directory ID: // MSSQL select * from cwd_directory Then I grab the users, which I usually tag with a temporary group: // MSSQL select * from cwd_user where directory_id = '####' -- Source directory ID and lower_user_name in ( select child_name from cwd_membership where parent_name = 'AccountsToMove' ) order by lower_user_name Then I grab the users' memberships: // MSSQL select parent_name,child_name from cwd_membership where directory_id = '####' and child_name in( select lower_child_name from cwd_membership where parent_name = 'AccountsToMove' ) Order by child_name,parent_name Then I use these files for the CSV import to the new directory. NOTE: even though you're using delegated LDAP, you'll still need to have a password column. Doesn't matter what text you put in there, as Crowd will execute an AD lookup at the moment of logon and update this value as expected, so it's just a placeholder. Once the users have synced down to the client apps, then I delete them from the source directory and send out the 'migration complete' mail. So far for us, this has all been very safe and easy to do.

            bn273340 added a comment -

            Thanks April, I think you just saved me a ton of a time.  I searched the Atlassian documentation for a couple days trying to find out if new Crowd DB IDs would make client apps (jira, conf, bitbucket, etc) see the user as "new" and came up with nothing.  

            Maybe as a workaround Atlassian can post some official documentation that includes the queries to find, at the very minimum, the group memberships of the users you wish to move.  I would also suggest they put in a note that this method won't cause issues with client apps.  

            The queries aren't hard to figure out but not knowing what fresh havoc I may release upon Jira and Conf made me reluctant to try it.  

            bn273340 added a comment - Thanks April, I think you just saved me a ton of a time.  I searched the Atlassian documentation for a couple days trying to find out if new Crowd DB IDs would make client apps (jira, conf, bitbucket, etc) see the user as "new" and came up with nothing.   Maybe as a workaround Atlassian can post some official documentation that includes the queries to find, at the very minimum, the group memberships of the users you wish to move.  I would also suggest they put in a note that this method won't cause issues with client apps.   The queries aren't hard to figure out but not knowing what fresh havoc I may release upon Jira and Conf made me reluctant to try it.  

            April added a comment -

            Hi Joshua,

            Just to be clear, I am not editing anything in the DB; I am merely reading the DB data to create an import file, then using the standard CSV import function. This requires a group membership file as well as a user file, so missing groups are created by the importer in the target directory (NOTE: group descriptions must be added manually).

            For our environment, having new IDs in the Crowd DB causes no pain at all. As long as the username matches, the client applications see no change at all, at least through Jira 8.1/Confluence 6.13, and I can verify that the user ID's don't change in the client apps. I have some users who have moved four times over the last few years, without incident.

            That said, a Crowd GUI option to select a different directory for a user would be amazing.

            Perhaps even more amazing would be the ability to select multiple users for deletion, as I can bulk import as many as I want, but then I have to delete the old accounts one by painful one.... 

            April added a comment - Hi Joshua, Just to be clear, I am not editing anything in the DB; I am merely reading the DB data to create an import file, then using the standard CSV import function. This requires a group membership file as well as a user file, so missing groups are created by the importer in the target directory (NOTE: group descriptions must be added manually). For our environment, having new IDs in the Crowd DB causes no pain at all. As long as the username matches, the client applications see no change at all, at least through Jira 8.1/Confluence 6.13, and I can verify that the user ID's don't change in the client apps. I have some users who have moved four times over the last few years, without incident. That said, a Crowd GUI option to select a different directory for a user would be amazing. Perhaps even more amazing would be the ability to select multiple users for deletion, as I can bulk import as many as I want, but then I have to delete the old accounts one by painful one.... 

            bn273340 added a comment -

            April,

            Have you seen any ramifications to your approach when moving users from one directory to another as far as Jira and Confluence are concerned?  Your approach creates new unique IDs in the Crowd database which I'm worried would create a problem linking issue assignee, reporters, etc.  

            I think the ask to avoid "pain", as you put it, is to simply select a user, or bulk set of users, and move them to a new directory keeping their DB ID the exact same.  To really flesh this out I would like to see the option to move/create missing groups in the import directory as well.

            All of this can be done in the database but its risky and your users end up with no groups, or attributes while you are running the queries.  In a crowd instance with roughly 4000 active users I try not to much about in the database much.

            bn273340 added a comment - April, Have you seen any ramifications to your approach when moving users from one directory to another as far as Jira and Confluence are concerned?  Your approach creates new unique IDs in the Crowd database which I'm worried would create a problem linking issue assignee, reporters, etc.   I think the ask to avoid "pain", as you put it, is to simply select a user, or bulk set of users, and move them to a new directory keeping their DB ID the exact same.  To really flesh this out I would like to see the option to move/create missing groups in the import directory as well. All of this can be done in the database but its risky and your users end up with no groups, or attributes while you are running the queries.  In a crowd instance with roughly 4000 active users I try not to much about in the database much.

            April added a comment -

            Hi Wim,

            We are using "Delegated authentication" directories. When we needed to migrate domain users, our requirement was to move users in small batches. I found it handy to simply query the DB for the list of desired users and their group memberships. Then I used that data to create a CSV import file, and deleted the old accounts after importing to the new directory. Not elegant, but bonus, the importer will create any missing groups in the target directory, which saves time. 

            That said, no matter what you do or how convenient the method, there will always be pain

            April added a comment - Hi Wim, We are using "Delegated authentication" directories. When we needed to migrate domain users, our requirement was to move users in small batches. I found it handy to simply query the DB for the list of desired users and their group memberships. Then I used that data to create a CSV import file, and deleted the old accounts after importing to the new directory. Not elegant, but bonus, the importer will create any missing groups in the target directory, which saves time.  That said, no matter what you do or how convenient the method, there will always be pain

            We are assessing the amount of work that needs to be done to move users from one domain to another. We are hitting the 2000 users limit ... I hope it will not be a pain

            Running 7.9.2

            Wim Kerstens added a comment - We are assessing the amount of work that needs to be done to move users from one domain to another. We are hitting the 2000 users limit ... I hope it will not be a pain Running 7.9.2

            Adam Kolb added a comment -

            Here we are in version 7, and still don't have this capability.  Seems like such a simple update.  This would save me dozens of hour in user maintenance, as we are managing 3 different domains and users switch quite often.  I currently have over 300 users that need to be moved into a new user directory, but do not want to move the other 400.

            Adam Kolb added a comment - Here we are in version 7, and still don't have this capability.  Seems like such a simple update.  This would save me dozens of hour in user maintenance, as we are managing 3 different domains and users switch quite often.  I currently have over 300 users that need to be moved into a new user directory, but do not want to move the other 400.

            It would be amazing to have the capability to move a single user or a bulk of user from a directory to another.

            Right now I have to inactive users and create them again, and it is quite bad.

            Omry Hassan added a comment - It would be amazing to have the capability to move a single user or a bulk of user from a directory to another. Right now I have to inactive users and create them again, and it is quite bad.

            Although the Crowd CWD issue does not have that many direct votes, it seems - from the links - that the lack of this capability blocks many migration scenarios in both Confluence and JIRA for both Cloud and Server's embedded crowd.

            People who vote in Crowd are typically people from central I.T., each of whom represents deep understanding, complex use-cases and who is often influential for advocating to the C-Suite for the enterprise-readiness of Atlassian solutions.

            This issue will be 10 years in Feb.

            Martin Cleaver added a comment - Although the Crowd CWD issue does not have that many direct votes, it seems - from the links - that the lack of this capability blocks many migration scenarios in both Confluence and JIRA for both Cloud and Server's embedded crowd. People who vote in Crowd are typically people from central I.T., each of whom represents deep understanding, complex use-cases and who is often influential for advocating to the C-Suite for the enterprise-readiness of Atlassian solutions. This issue will be 10 years in Feb.

            I must agree with April. THe shifting arrangements and dynamics of modern companies is too complex to not have the ability to migrate users between directories. Essentially its the difference between using Crowd for Atlassian products ontop of a directory solution or using Crowd as the directory solution. 

            Platforma Billing added a comment - I must agree with April. THe shifting arrangements and dynamics of modern companies is too complex to not have the ability to migrate users between directories. Essentially its the difference between using Crowd for Atlassian products ontop of a directory solution or using Crowd as the directory solution. 

              Unassigned Unassigned
              f89a0b0da16c Amen Hamdan
              Votes:
              116 Vote for this issue
              Watchers:
              64 Start watching this issue

                Created:
                Updated: