• 297
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.

      Atlassian Status as of 22 May 2013

      Hi everyone,

      Thanks so much for your votes and comments on this issue.

      JIRA 6.0 has been released with the ability to edit usernames and we all hope you take it for a spin! JIRA 6.0 contains lots of other goodness and you can read the full release notes here.

      Cheers,

      Roy
      JIRA Product Management
      roy at atlassian dot com

        1. D3904554-8F1C-8F48-9B44-FF092AD4E845
          7 kB
        2. D3904554-8F1C-8F48-9B44-FF092AD4E845
          7 kB
        3. D3904554-8F1C-8F48-9B44-FF092AD4E845
          7 kB
        4. D3904554-8F1C-8F48-9B44-FF092AD4E845
          7 kB
        5. D3904554-8F1C-8F48-9B44-FF092AD4E845
          7 kB
        6. Edit_Profile_615.png
          Edit_Profile_615.png
          61 kB
        7. edit_username.png
          edit_username.png
          145 kB
        8. jira_renameuser_all.sql
          4 kB
        9. jira_user_migration_5.2_Postgresql_9.2_v2.sql
          6 kB
        10. jira_user_migration_5.2_Postgresql_9.2.sql
          6 kB
        11. jira_user_migration 5.2.sql
          4 kB
        12. OracleDB-UserNameUpdate-SQL-Jira3.13.4-Enterprise.txt
          7 kB
        13. renameuser.sql
          2 kB
        14. screenshot-1.jpg
          screenshot-1.jpg
          21 kB
        15. Search_list.csv
          1 kB
        16. TableData Find and Replace.sql
          2 kB
        17. TableDataSearch.sql
          2 kB
        18. update_username_jira_6.2.6.sql
          2 kB

            [JRASERVER-1549] Ability to rename a user

            @Citrix Devops
            thanks for your response. see my response in line with your comments.
            From my experience, you can rename users in LDAP or in Crowd and JIRA will pick them up (assuming that JIRA is connected to Crowd).
            Yes, we expected it should work like that, but it is not, with earlier it was working like this, i suppose.

            Still, the same operation will not work on Confluence, as it would confuse it badly.
            yes, Confluence is not updating with user changes

            Still, I do think that the the ability to merge users is not here and the hacks for implementing it are really ugly.
            I read many users had issues with DB side hack, we need to have good scripts to change all of them good, otherwise it will corrupt data!!

            Raju Adluru added a comment - @Citrix Devops thanks for your response. see my response in line with your comments. From my experience, you can rename users in LDAP or in Crowd and JIRA will pick them up (assuming that JIRA is connected to Crowd). Yes, we expected it should work like that, but it is not, with earlier it was working like this, i suppose. Still, the same operation will not work on Confluence, as it would confuse it badly. yes, Confluence is not updating with user changes Still, I do think that the the ability to merge users is not here and the hacks for implementing it are really ugly. I read many users had issues with DB side hack, we need to have good scripts to change all of them good, otherwise it will corrupt data!!

            @Mark Lassau
            Thanks for your reply.
            Yes you got it right, currently we use AD also for authentication connected thro crowd.

            Answers to your Qs
            Do you want to connect JIRA directly to AD or do you want JIRA connected to Crowd and Crowd gets user data from AD?
            we want JIRA connected thro Crowd, crowd gets users from AD.
            Do the usernames in AD match the current usernames in Crowd internal directory?
            No, crowd internal users have different convention like - xx-fristname-lastname, AD has "yxxxxx" y - first letter of first name, xxxxx - last name
            If usernames don't match, how many are different? Is there a simple rule for how to change them or are the changes "random"?
            we have around 130 of them, which have same convention, they are not random. we can bulk change them, or one by one.

            We want JIRA or Confluence issue history intact for Crowd internal users, when we merge user with AD.

            Thanks
            Raju

            Raju Adluru added a comment - @Mark Lassau Thanks for your reply. Yes you got it right, currently we use AD also for authentication connected thro crowd. Answers to your Qs Do you want to connect JIRA directly to AD or do you want JIRA connected to Crowd and Crowd gets user data from AD? we want JIRA connected thro Crowd, crowd gets users from AD. Do the usernames in AD match the current usernames in Crowd internal directory? No, crowd internal users have different convention like - xx-fristname-lastname, AD has "yxxxxx" y - first letter of first name, xxxxx - last name If usernames don't match, how many are different? Is there a simple rule for how to change them or are the changes "random"? we have around 130 of them, which have same convention, they are not random. we can bulk change them, or one by one. We want JIRA or Confluence issue history intact for Crowd internal users, when we merge user with AD. Thanks Raju

            intersol_old added a comment -

            From my experience, you can rename users in LDAP or in Crowd and JIRA will pick them up (assuming that JIRA is connected to Crowd).

            Still, the same operation will not work on Confluence, as it would confuse it badly.

            Still, I do think that the the ability to merge users is not here and the hacks for implementing it are really ugly.

            We do have to rename/merge users quite often because we do import data from other systems where users had different usernames and you inevitably end-up with having both the current user, with his content and the old user where you want to merge into the new one. So far we performed these at database level, really ugly.

            intersol_old added a comment - From my experience, you can rename users in LDAP or in Crowd and JIRA will pick them up (assuming that JIRA is connected to Crowd). Still, the same operation will not work on Confluence, as it would confuse it badly. Still, I do think that the the ability to merge users is not here and the hacks for implementing it are really ugly. We do have to rename/merge users quite often because we do import data from other systems where users had different usernames and you inevitably end-up with having both the current user, with his content and the old user where you want to merge into the new one. So far we performed these at database level, really ugly.

            radluru
            If I understand then you currently have JIRA connected to Crowd and users are stored in a Crowd internal directory.
            Now you want to change to having users coming from MS AD.
            Same situation for Confluence.

            Questions:

            • Do you want to connect JIRA directly to AD or do you want JIRA connected to Crowd and Crowd gets user data from AD?
            • Do the usernames in AD match the current usernames in Crowd internal directory?
            • If usernames don't match, how many are different? Is there a simple rule for how to change them or are the changes "random"?

            Mark Lassau (Inactive) added a comment - radluru If I understand then you currently have JIRA connected to Crowd and users are stored in a Crowd internal directory. Now you want to change to having users coming from MS AD. Same situation for Confluence. Questions: Do you want to connect JIRA directly to AD or do you want JIRA connected to Crowd and Crowd gets user data from AD? Do the usernames in AD match the current usernames in Crowd internal directory? If usernames don't match, how many are different? Is there a simple rule for how to change them or are the changes "random"?

            Hi Guys
            can somebody help us for user mapping for our scenario.
            JIRA v6.3.12 (recently upgrade from 6.2), Crowd 2.8.0( recently upgrade from 2.7.0) connects to MS AD, Confluence 5.6.5
            DB- MS SQL 2012

            JIRA --> Crowd < ----> MS AD
            Internal Dir Internal Dir
            people used their user ids from JIRA Internal Dir and Crowd Internal Dir and created issues in JIRA, now we want to map all those users to AD accounts.
            Can above scripts will help me to map and change these users.

            Same scenario for Confluence also, users created contect with their Crowd internal Ids, we want map them to AD user accounts, how can i do this.
            Jamie disabled his rename and merge user from Script runner also!

            In old Crowd 2.7, my colleague says he did rename user in crowd internal, it picked up AD user and merged, not sure about this, can somebody confirm this, if that is case, i can go back to crowd 2.7 and try that.
            Appreciate your help.
            Thanks

            Raju Adluru added a comment - Hi Guys can somebody help us for user mapping for our scenario. JIRA v6.3.12 (recently upgrade from 6.2), Crowd 2.8.0( recently upgrade from 2.7.0) connects to MS AD, Confluence 5.6.5 DB- MS SQL 2012 JIRA --> Crowd < ----> MS AD Internal Dir Internal Dir people used their user ids from JIRA Internal Dir and Crowd Internal Dir and created issues in JIRA, now we want to map all those users to AD accounts. Can above scripts will help me to map and change these users. Same scenario for Confluence also, users created contect with their Crowd internal Ids, we want map them to AD user accounts, how can i do this. Jamie disabled his rename and merge user from Script runner also! In old Crowd 2.7, my colleague says he did rename user in crowd internal, it picked up AD user and merged, not sure about this, can somebody confirm this, if that is case, i can go back to crowd 2.7 and try that. Appreciate your help. Thanks

            Ivan Kovnatsky added a comment - - edited

            Hi guys, in case if someone needs updated script for renaming usernames in JIRA ~6.2.6 here it is. I've added only the tables we really needed to be updated, don't consider this any semi-official thing.

            Ivan Kovnatsky added a comment - - edited Hi guys, in case if someone needs updated script for renaming usernames in JIRA ~6.2.6 here it is. I've added only the tables we really needed to be updated, don't consider this any semi-official thing.

            We are using v6.2.6. We tried editing the username and it worked. But unfortunately, past comments (where the user was mentioned) of the user we edited were not updated to the new one, it displays the previous username. Is this a current limitation?

            edilberto.balanak
            Sorry for late reply.

            Your are correct - this is a limitation.
            Because the "mentions" in comments are really just some formatting text inside a free form text field there is no easy way to rename all of these.
            We would have to load up all comments (potentially millions) and parse the text / wiki markup and look for patterns like [~old-username] and edit these ...

            Mark Lassau (Inactive) added a comment - We are using v6.2.6. We tried editing the username and it worked. But unfortunately, past comments (where the user was mentioned) of the user we edited were not updated to the new one, it displays the previous username. Is this a current limitation? edilberto.balanak Sorry for late reply. Your are correct - this is a limitation. Because the "mentions" in comments are really just some formatting text inside a free form text field there is no easy way to rename all of these. We would have to load up all comments (potentially millions) and parse the text / wiki markup and look for patterns like [~old-username] and edit these ...

            que bizarrice! como é possível não poder renomear um usuário? Que tipode engenhoca foi construída?

            1. se você criar um usuário, fazer dele líder de um projeto.
            2. se você um dia renomear este usuário, o banco não atualiza.

            qual o problema? é cache? nunca ouviu falar de cache flush?

            como que resolve essa gororoba?

            ricardo wolosker added a comment - que bizarrice! como é possível não poder renomear um usuário? Que tipode engenhoca foi construída? se você criar um usuário, fazer dele líder de um projeto. se você um dia renomear este usuário, o banco não atualiza. qual o problema? é cache? nunca ouviu falar de cache flush? como que resolve essa gororoba?

            Sure - let's take this offline and over to Questions just so we don't spam everyone while we're figuring it out - we can post the 'fix' here when we're done. I'll post the question from your original post .... well, here's the link to your questions post:

            https://answers.atlassian.com/questions/320093/asked-by-martin-hanke-unable-to-rename-a-jira-local-user-no-option#

            -wc

            William Crighton [CCC] added a comment - Sure - let's take this offline and over to Questions just so we don't spam everyone while we're figuring it out - we can post the 'fix' here when we're done. I'll post the question from your original post .... well, here's the link to your questions post: https://answers.atlassian.com/questions/320093/asked-by-martin-hanke-unable-to-rename-a-jira-local-user-no-option# -wc

            Martin Hanke added a comment - - edited

            Hi William, thx for your quick reply. Well, I have tried that already. Please have a look at the attached screenshot. There is no 3rd field available...

            Any Ideas?
            Martin

            Martin Hanke added a comment - - edited Hi William, thx for your quick reply. Well, I have tried that already. Please have a look at the attached screenshot. There is no 3rd field available... Any Ideas? Martin

            Martin,

            I believe you need to navigate to Administration/User Management/<your user - click their name> and then click the 'Actions' button on the right and select 'edit profile' - you should then see a 3 field model dialog with the first field being their editable user name.

            -wc

            William Crighton [CCC] added a comment - Martin, I believe you need to navigate to Administration/User Management/<your user - click their name> and then click the 'Actions' button on the right and select 'edit profile' - you should then see a 3 field model dialog with the first field being their editable user name. -wc

            Hi all,

            we are running JIRA version 6.1.5 with an internal user directory. Unfortunately, there is no 'username' field in the 'Edit Profile' wizard. Are there any settings I have to maintain in order to be able to change the username?

            Martin Hanke added a comment - Hi all, we are running JIRA version 6.1.5 with an internal user directory. Unfortunately, there is no 'username' field in the 'Edit Profile' wizard. Are there any settings I have to maintain in order to be able to change the username?

            Don Balanak added a comment - - edited

            Hi,

            We are using v6.2.6. We tried editing the username and it worked. But unfortunately, past comments (where the user was mentioned) of the user we edited were not updated to the new one, it displays the previous username. Is this a current limitation?

            Don Balanak added a comment - - edited Hi, We are using v6.2.6. We tried editing the username and it worked. But unfortunately, past comments (where the user was mentioned) of the user we edited were not updated to the new one, it displays the previous username. Is this a current limitation?

            Thanks Helen!

            Normand Carbonneau added a comment - Thanks Helen!

            Hi ncarbonneau You are right, it has not yet been implemented in OnDemand. We do have a ticket for that one specifically, if you'd like to track it: https://jira.atlassian.com/browse/AOD-7010?filter=46621

            Helen Hung (Inactive) added a comment - Hi ncarbonneau You are right, it has not yet been implemented in OnDemand. We do have a ticket for that one specifically, if you'd like to track it: https://jira.atlassian.com/browse/AOD-7010?filter=46621

            Is it me or this issue has never been solved for On-Demand users?

            Normand Carbonneau added a comment - Is it me or this issue has never been solved for On-Demand users?

            jfireham1 / atlassian@ambientia.fi When I test this, it works fine for me.

            I can only guess that you are either misinterpreting the instructions, or running into a problem specific to your environment.
            I suggest you raise a support ticket.

            Mark Lassau (Inactive) added a comment - jfireham1 / atlassian@ambientia.fi When I test this, it works fine for me. I can only guess that you are either misinterpreting the instructions, or running into a problem specific to your environment. I suggest you raise a support ticket.

            Ambientia added a comment -

            Hi Joel,

            Im battling the exact same thing as we speak. Im also running JIRA 6.1.7 and Crowd 2.6. and disabling Crowd and renaming the user locally to the format of the Crowd remote user does not "migrate" the issues to the new remote user.

            Ambientia added a comment - Hi Joel, Im battling the exact same thing as we speak. Im also running JIRA 6.1.7 and Crowd 2.6. and disabling Crowd and renaming the user locally to the format of the Crowd remote user does not "migrate" the issues to the new remote user.

            joelfire added a comment -

            Thanks Mark.
            No, I'm not connecting to both Crowd and LDAP on JIRA. I am only connecting to Crowd; Crowd is serving up both the old LDAP and new AD directories to JIRA.

            So yes, the steps you outlined is what I did. I tried it again, and the same thing happens. That is:

            5. Rename dsmith to davsmith
            At this stage there is no longer a dsmith in the system.
            ABC-1 is assigned to davsmith

            There is no longer a dsmith in the system, however, ABC-1 is not assigned to davsmith, it is still assigned to 'dsmith' which is now grey and no longer a link (being no longer in the system.)
            FYI I am on JIRA 6.1.5.
            Changing the name in LDAP or adding old usernames to the new AD server are not options for me (and I don't think it will work since JIRA does not connect to LDAP, it connects to Crowd.)
            I'll hit up support, just logging this comment for the sake of others that may hit this.

            joelfire added a comment - Thanks Mark. No, I'm not connecting to both Crowd and LDAP on JIRA. I am only connecting to Crowd; Crowd is serving up both the old LDAP and new AD directories to JIRA. So yes, the steps you outlined is what I did. I tried it again, and the same thing happens. That is: 5. Rename dsmith to davsmith At this stage there is no longer a dsmith in the system. ABC-1 is assigned to davsmith There is no longer a dsmith in the system, however, ABC-1 is not assigned to davsmith, it is still assigned to 'dsmith' which is now grey and no longer a link (being no longer in the system.) FYI I am on JIRA 6.1.5. Changing the name in LDAP or adding old usernames to the new AD server are not options for me (and I don't think it will work since JIRA does not connect to LDAP, it connects to Crowd.) I'll hit up support, just logging this comment for the sake of others that may hit this.

            Although the above will work, it may be preferable in some cases to do the rename in the LDAP server or in the AD server itself and have JIRA pick up the change.
            This requires JIRA 6.1.1 or higher (requires JRA-32200 / JRA-32199).

            The advantage to this procedure is that you only need to rename once in LDAP and all the connected applications should be able to detect the change.
            The downside is that you may need to co-ordinate with those other applications to make sure that they can handle the rename.
            It also may be difficult or impossible for you to effect these changes in the LDAP server due to technical or operational limitations.

            I am covering the case that jfireham1 states of connecting to LDAP via Crowd. Customers connecting directly to LDAP will be able to follow a similar (simpler) procedure.

            Option 1 - Rename users in the old LDAP before migrating to the new AD server

            1. Update to JIRA 6.1.1 or higher and Crowd 2.7
            2. Synchronise the LDAP directory in your Crowd server.
            (This is to pull down the user ID that we use to detect renames in LDAP)
            If you have been running the updated Crowd version for a while, then the automatic synchs should have already done this.
            3. Synchronise the Crowd directory in JIRA
            (To get those IDs into JIRA now that Crowd knows them.)
            If you have been running the updated JIRA and Crowd versions for a while, then the automatic synchs should have already done this for you.
            4. Rename the user in the LDAP directory
            5. Manually synch the LDAP directory in Crowd or wait for the auto synch to occur
            6. Manually synch the Crowd directory in JIRA or wait for the auto synch to occur
            JIRA should detect the rename and the username should be changed.
            eg dsmith is now renamed to davsmith and ABC-1 is assigned to davsmith
            7. You are now ready to cut Crowd over from the LDAP server to the AD server.

            Option 2 - First put the old usernames in the new AD server, and then rename them later.

            I will leave the details out as they are similar to Option 1.
            This would obviously require planning because if the new names are already added to the new AD server then it is probably too late.

            Mark Lassau (Inactive) added a comment - Although the above will work, it may be preferable in some cases to do the rename in the LDAP server or in the AD server itself and have JIRA pick up the change. This requires JIRA 6.1.1 or higher (requires JRA-32200 / JRA-32199 ). The advantage to this procedure is that you only need to rename once in LDAP and all the connected applications should be able to detect the change. The downside is that you may need to co-ordinate with those other applications to make sure that they can handle the rename. It also may be difficult or impossible for you to effect these changes in the LDAP server due to technical or operational limitations. I am covering the case that jfireham1 states of connecting to LDAP via Crowd. Customers connecting directly to LDAP will be able to follow a similar (simpler) procedure. Option 1 - Rename users in the old LDAP before migrating to the new AD server 1. Update to JIRA 6.1.1 or higher and Crowd 2.7 2. Synchronise the LDAP directory in your Crowd server. (This is to pull down the user ID that we use to detect renames in LDAP) If you have been running the updated Crowd version for a while, then the automatic synchs should have already done this. 3. Synchronise the Crowd directory in JIRA (To get those IDs into JIRA now that Crowd knows them.) If you have been running the updated JIRA and Crowd versions for a while, then the automatic synchs should have already done this for you. 4. Rename the user in the LDAP directory 5. Manually synch the LDAP directory in Crowd or wait for the auto synch to occur 6. Manually synch the Crowd directory in JIRA or wait for the auto synch to occur JIRA should detect the rename and the username should be changed. eg dsmith is now renamed to davsmith and ABC-1 is assigned to davsmith 7. You are now ready to cut Crowd over from the LDAP server to the AD server. Option 2 - First put the old usernames in the new AD server, and then rename them later. I will leave the details out as they are similar to Option 1. This would obviously require planning because if the new names are already added to the new AD server then it is probably too late.

            Mark Lassau (Inactive) added a comment - - edited

            William is right - that trick should work for you in JIRA 6.0 or higher.
            (There other ways that may also work for you in JIRA 6.1 ... but we can come back to these later)

            You say that assignments etc are still dsmith instead of davsmith.
            Are you sure that renamed dsmith -> davsmith correctly at step 2.?

            At Step 2. (rename 'dsmith' to 'davsmith') this re-assignment should have already occurred.
            There should no longer even be a dsmith user existing to have those assignments...
            (once you actually disconnect the old LDAP server .. it sound like you are connecting to both AD and LDAP at the same time which is legal, but probably not what you want)

            Let me re-iterate William's steps but be a bit more explicit:

            1. Initial state is that JIRA is connected to Crowd and Crowd is connected to LDAP 1
            In JIRA you have a user called 'dsmith' who is coming from LDAP 1 via Crowd and lets say he is the assignee for issue ABC-1

            2. Login to a JIRA admin account in the Internal Directory
            Obviously you will need to enable the Internal Directory if it was previously disabled.

            3. Disable the Crowd Directory

            4. Check if you still have a dsmith user
            The internal User directory may already have a dsmith defined (it sounds like in your case this is true), or it may not.
            If not, simply create a user with a username of 'dsmith'.
            This user is still the assignee of ABC-1

            5. Rename dsmith to davsmith
            At this stage there is no longer a dsmith in the system.
            ABC-1 is assigned to davsmith

            6. Go to Crowd and change the definition of the Crowd "application" that JIRA is connecting to.
            Previously it was connected to the "LDAP 1" directory.
            Remove this directory and add the new AD directory instead.
            (Alternatively you could create a second "application" in Crowd and then update JIRA to point at this application instead of the old one ... this may be useful if you are working on a test server and the prod server needs to connect to the old setup still)
            "Synchronise" the AD directory in Crowd if it is new - this will pull down the users from AD.
            Do a search in Crowd to confirm that davsmith now exists in the AD directory.

            7. In JIRA, synchronise the disabled Crowd directory
            (don't forget to edit it first, if you are using a new "application" name in Crowd)

            8. Enable the Crowd directory and ensure it is sitting above the Internal directory
            davsmith is coming from AD via Crowd.
            There is no dsmith user in JIRA at all, because we no longer even connect to LDAP 1 via Crowd.
            ABC-1 is assigned to davsmith.

            If problems persist, you can create a support ticket.

            Mark Lassau (Inactive) added a comment - - edited William is right - that trick should work for you in JIRA 6.0 or higher. (There other ways that may also work for you in JIRA 6.1 ... but we can come back to these later) You say that assignments etc are still dsmith instead of davsmith. Are you sure that renamed dsmith -> davsmith correctly at step 2.? At Step 2. (rename 'dsmith' to 'davsmith') this re-assignment should have already occurred. There should no longer even be a dsmith user existing to have those assignments... (once you actually disconnect the old LDAP server .. it sound like you are connecting to both AD and LDAP at the same time which is legal, but probably not what you want) Let me re-iterate William's steps but be a bit more explicit: 1. Initial state is that JIRA is connected to Crowd and Crowd is connected to LDAP 1 In JIRA you have a user called 'dsmith' who is coming from LDAP 1 via Crowd and lets say he is the assignee for issue ABC-1 2. Login to a JIRA admin account in the Internal Directory Obviously you will need to enable the Internal Directory if it was previously disabled. 3. Disable the Crowd Directory 4. Check if you still have a dsmith user The internal User directory may already have a dsmith defined (it sounds like in your case this is true), or it may not. If not, simply create a user with a username of 'dsmith'. This user is still the assignee of ABC-1 5. Rename dsmith to davsmith At this stage there is no longer a dsmith in the system. ABC-1 is assigned to davsmith 6. Go to Crowd and change the definition of the Crowd "application" that JIRA is connecting to. Previously it was connected to the "LDAP 1" directory. Remove this directory and add the new AD directory instead. (Alternatively you could create a second "application" in Crowd and then update JIRA to point at this application instead of the old one ... this may be useful if you are working on a test server and the prod server needs to connect to the old setup still) "Synchronise" the AD directory in Crowd if it is new - this will pull down the users from AD. Do a search in Crowd to confirm that davsmith now exists in the AD directory. 7. In JIRA, synchronise the disabled Crowd directory (don't forget to edit it first, if you are using a new "application" name in Crowd) 8. Enable the Crowd directory and ensure it is sitting above the Internal directory davsmith is coming from AD via Crowd. There is no dsmith user in JIRA at all, because we no longer even connect to LDAP 1 via Crowd. ABC-1 is assigned to davsmith. If problems persist, you can create a support ticket.

            joelfire added a comment -

            Thanks for the post, William, but it doesn't seem to work for me.
            There is a used called 'dsmith' in the old LDAP server, and 'davsmith' in the new AD server.
            Both are being used by JIRA for authentication via Crowd.

            1. I disabled Crowd, then logged in as a local admin.
            2. I was then able to see that 'dsmith' was now in the internal directory. I renamed to 'davsmith'
            3. Then enabled Crowd. 'davsmith' is now in the crowd directory

            But none of the history of 'dsmith' changed to 'davsmith'. Assignments, comments, etc. They are all still 'dsmith'

            Missing something?

            joelfire added a comment - Thanks for the post, William, but it doesn't seem to work for me. There is a used called 'dsmith' in the old LDAP server, and 'davsmith' in the new AD server. Both are being used by JIRA for authentication via Crowd. I disabled Crowd, then logged in as a local admin. I was then able to see that 'dsmith' was now in the internal directory. I renamed to 'davsmith' Then enabled Crowd. 'davsmith' is now in the crowd directory But none of the history of 'dsmith' changed to 'davsmith'. Assignments, comments, etc. They are all still 'dsmith' Missing something?

            I'm not sure what they said but I can confirm this can be done - and you don't have to be on JIRA 6.1, just some post JIRA 6.0 release.
            The process is this - and thank you to the Rocket guys who brought this up in another (or earlier in this) thread having the Atlassian engineer more clearly describe how the process works – which, from what I can tell, can be subverted via ignorance in a 3rd party plugin. But anyway...

            Per your use case you have an established ldap system with first initial last name usernames and you need to merge that into the new company 'standard' (I love standards...there's so many to choose from!) which is first name dot last name. The following process takes care of this desired translation though it is a bit time consuming/complicated - primarily b/c part of the change requires you to break the JIRA/external authenticator connection:

            1. get list of all users you wish to rename
            2. create a JIRA local admin account (should always have one of these)
            3. disconnect the external authentication system (AD, OpenLDAP, whatever)
            4. rename the JIRA local account to match the external authenticator account
            5. re-connect the external authenticator
            6. when the person who had their username change logs in next time they'll see every issue created as either user (username having been changed in each case to match their 'external' username. They will see this change throughout every JIRA package/plugin/add-on that supports the ApplicationUser object.

            Hope that helped
            -wc
            William Crighton
            Capital City Consultants LLC.

            William Crighton [CCC] added a comment - I'm not sure what they said but I can confirm this can be done - and you don't have to be on JIRA 6.1, just some post JIRA 6.0 release. The process is this - and thank you to the Rocket guys who brought this up in another (or earlier in this) thread having the Atlassian engineer more clearly describe how the process works – which, from what I can tell, can be subverted via ignorance in a 3rd party plugin. But anyway... Per your use case you have an established ldap system with first initial last name usernames and you need to merge that into the new company 'standard' (I love standards...there's so many to choose from!) which is first name dot last name. The following process takes care of this desired translation though it is a bit time consuming/complicated - primarily b/c part of the change requires you to break the JIRA/external authenticator connection: get list of all users you wish to rename create a JIRA local admin account (should always have one of these) disconnect the external authentication system (AD, OpenLDAP, whatever) rename the JIRA local account to match the external authenticator account re-connect the external authenticator when the person who had their username change logs in next time they'll see every issue created as either user (username having been changed in each case to match their 'external' username. They will see this change throughout every JIRA package/plugin/add-on that supports the ApplicationUser object. Hope that helped -wc William Crighton Capital City Consultants LLC.

            joelfire added a comment -

            Ok, so now I am confused. This seems to only address the internal directory. Which would not be used by any serious organization, you use LDAP or Crowd.

            A classic use case for renaming a user is:

            1. My company uses Crowd for authentication via our LDAP server
            2. My company is bought by another company, and we get new usernames on their AD that differ from ours. My username is 'foo' on LDAP and 'fubar' on AD
            3. My new company wants us to shut down our LDAP server and authenticate usinf AD

            So now I can add their AD server to Crowd. But I want to maintain the history of my user. I want to rename 'foo' in JIRA to 'fubar' for all historical entries: creates, resolves, comments, etc.

            You're saying that I can't do this?

            joelfire added a comment - Ok, so now I am confused. This seems to only address the internal directory. Which would not be used by any serious organization, you use LDAP or Crowd. A classic use case for renaming a user is: My company uses Crowd for authentication via our LDAP server My company is bought by another company, and we get new usernames on their AD that differ from ours. My username is 'foo' on LDAP and 'fubar' on AD My new company wants us to shut down our LDAP server and authenticate usinf AD So now I can add their AD server to Crowd. But I want to maintain the history of my user. I want to rename 'foo' in JIRA to 'fubar' for all historical entries: creates, resolves, comments, etc. You're saying that I can't do this?

            mlassau,

            Enable Incremental Synchronisation is by default turned off. I checked it
            once again. Thanks for heads up.

            Ivan Kovnatsky added a comment - mlassau , Enable Incremental Synchronisation is by default turned off. I checked it once again. Thanks for heads up.

            PS, if you are using Crowd, please be sure to set "full synchronisation" not "incremental synchronisation" - the incremental synch is not yet smart enough to understand user renames.

            Mark Lassau (Inactive) added a comment - PS, if you are using Crowd, please be sure to set "full synchronisation" not "incremental synchronisation" - the incremental synch is not yet smart enough to understand user renames.

            Mark,

            Thank you for clarifications.

            Ivan Kovnatsky added a comment - Mark, Thank you for clarifications.

            jose (ericsson)

            Since we are planning the Jira 6.x upgrade, we hope, it will work also by using an external user directory as we do.

            As I mention above, you need JIRA v6.1 or higher in order to be able to detect renames from an external user directory.
            If the external directory is a Crowd server, then it needs to be Crowd v2.7.0 or higher.

            Mark Lassau (Inactive) added a comment - jose (ericsson) Since we are planning the Jira 6.x upgrade, we hope, it will work also by using an external user directory as we do. As I mention above, you need JIRA v6.1 or higher in order to be able to detect renames from an external user directory. If the external directory is a Crowd server, then it needs to be Crowd v2.7.0 or higher.

            i.kovnatskiy

            Could you please confirm that the problem exists and 6.0.8 and in 6.1.4 it is working as expected ?

            Yes, that is correct.

            Although JRA-1549 was marked as fixed in 6.0, at this stage we only added the ability to rename a user in an internal directory.
            The ability to detect a rename in an external directory (either LDAP or Crowd) was was added in v6.1
            See JRA-32199 and JRA-32200

            Mark Lassau (Inactive) added a comment - i.kovnatskiy Could you please confirm that the problem exists and 6.0.8 and in 6.1.4 it is working as expected ? Yes, that is correct. Although JRA-1549 was marked as fixed in 6.0, at this stage we only added the ability to rename a user in an internal directory. The ability to detect a rename in an external directory (either LDAP or Crowd) was was added in v6.1 See JRA-32199 and JRA-32200

            Hi guys,

            We're using external user directory (Crowd one). Today I've tried to rename a
            user using crowd's 2.7.0 feature for renaming usernames and faced the problem
            that after JIRA directory sync with the crowd, I haven't seen the change on
            app_user table where linking is done (JIRA 6.0.8/Oracle DB). Funny thing I
            have tested this on JIRA 6.1.4 (with MySQL db) and I understand that all
            entries with the old usernames are not changing, instead it creates a link:
            old_username -> new_username. So all worklogs/changeitem entries on the web
            are shown ok. In db I just see the old usernames, which is expected and
            logical.

            Actual result on JIRA 6.0.8:

            • after sync I see two entries in app_user:
              • 12344 old_username old_username
              • 23455 new_username new_username
            • and apparently I see new records with the new username (which breaks reports
              and statistics obviously)

            Expected result on JIRA 6.1.4:

            • linking is created in app_user all records are writing using the old_username
            • reports are building using the old_username as a reference and new username
              are shown as real user

            Could you please confirm that the problem exists and 6.0.8 and in 6.1.4 it is
            working as expected ? In that case, we'll be waiting for JIRA 6.1.4 upgrade.

            Thank you,
            Ivan.

            Ivan Kovnatsky added a comment - Hi guys, We're using external user directory (Crowd one). Today I've tried to rename a user using crowd's 2.7.0 feature for renaming usernames and faced the problem that after JIRA directory sync with the crowd, I haven't seen the change on app_user table where linking is done (JIRA 6.0.8/Oracle DB). Funny thing I have tested this on JIRA 6.1.4 (with MySQL db) and I understand that all entries with the old usernames are not changing, instead it creates a link: old_username -> new_username. So all worklogs/changeitem entries on the web are shown ok. In db I just see the old usernames, which is expected and logical. Actual result on JIRA 6.0.8: after sync I see two entries in app_user: 12344 old_username old_username 23455 new_username new_username and apparently I see new records with the new username (which breaks reports and statistics obviously) Expected result on JIRA 6.1.4: linking is created in app_user all records are writing using the old_username reports are building using the old_username as a reference and new username are shown as real user Could you please confirm that the problem exists and 6.0.8 and in 6.1.4 it is working as expected ? In that case, we'll be waiting for JIRA 6.1.4 upgrade. Thank you, Ivan.

            Since we are planning the Jira 6.x upgrade, we hope, it will work also by using an external user directory as we do.

            Jose (Ericsson GmbH) added a comment - Since we are planning the Jira 6.x upgrade, we hope, it will work also by using an external user directory as we do.

            James Allen added a comment - - edited

            Script Runner possibly?

            James Allen added a comment - - edited Script Runner possibly?

            Hi kathi.paquet, yes this is definitely on our radar but it won't be something that we'll be looking into until sometime next year.
            It's difficult to give you an accurate time frame right this moment as we won't be getting to it until we finish our current work, which is simplifying the existing user management experience in OnDemand. Once we've completed our current project, we'll be in a better state to estimate when we'll get to this.
            Thanks, Helen

            Helen Hung (Inactive) added a comment - Hi kathi.paquet , yes this is definitely on our radar but it won't be something that we'll be looking into until sometime next year. It's difficult to give you an accurate time frame right this moment as we won't be getting to it until we finish our current work, which is simplifying the existing user management experience in OnDemand. Once we've completed our current project, we'll be in a better state to estimate when we'll get to this. Thanks, Helen

            when will this be available for OnDemand?

            Kathi Paquet added a comment - when will this be available for OnDemand?

            Hi hostmaster1. Thank you for your comment.

            Our OnDemand infrastructure uses Crowd for user management. As of today JIRA + Crowd combination does not support user rename feature, but this is something we plan on fixing in the future. Please follow the JRA-32200 for details.

            Cheers,
            Bartek Gatz
            JIRA Product Manager

            Bartosz Gatz (Inactive) added a comment - Hi hostmaster1 . Thank you for your comment. Our OnDemand infrastructure uses Crowd for user management. As of today JIRA + Crowd combination does not support user rename feature, but this is something we plan on fixing in the future. Please follow the JRA-32200 for details. Cheers, Bartek Gatz JIRA Product Manager

            DACHCOM added a comment -

            your screenshot of 20/Jun/13 is nice, but there is simply still no option to edit a username in JIRA onDemand latest version. where can I find this?

            DACHCOM added a comment - your screenshot of 20/Jun/13 is nice, but there is simply still no option to edit a username in JIRA onDemand latest version. where can I find this?

            pdriggett, let me explain the process here.
            Addressing the JRA-1549 improvement request was necessary as a first step. I understand this is not a perfect solution and I appreciate your discontent of that fact. But please remember that there is also a second step: the user rename feature working for remote user repositories, which is captured under two improvement requests:

            • JRA-32199 (rename user in presence of LDAP)
            • and JRA-32200 (rename user in presence of Crowd)

            Step 1 had to be completed before we could do step 2, and I will not dive into the internal mechanics of JIRA to explain it (I am sure you understand the level of complexity we are speaking about here).

            But why did we divide the work in two steps in the first place? The only reason for that was to provide the user rename for simple case scenario sooner so that at least the subset of customers could use the properly built feature earlier. Mind that we are working on both JRA-32199 and JRA-32200 at this very moment, and provided we will not stumble upon unexpected roadblocks the solution will be available soon.

            I hope this explains the situation well.
            Thank you so much for your patience.

            Cheers,
            Bartek Gatz
            JIRA Product Manager

            Bartosz Gatz (Inactive) added a comment - pdriggett , let me explain the process here. Addressing the JRA-1549 improvement request was necessary as a first step . I understand this is not a perfect solution and I appreciate your discontent of that fact. But please remember that there is also a second step : the user rename feature working for remote user repositories, which is captured under two improvement requests: JRA-32199 (rename user in presence of LDAP) and JRA-32200 (rename user in presence of Crowd) Step 1 had to be completed before we could do step 2, and I will not dive into the internal mechanics of JIRA to explain it (I am sure you understand the level of complexity we are speaking about here). But why did we divide the work in two steps in the first place? The only reason for that was to provide the user rename for simple case scenario sooner so that at least the subset of customers could use the properly built feature earlier. Mind that we are working on both JRA-32199 and JRA-32200 at this very moment, and provided we will not stumble upon unexpected roadblocks the solution will be available soon. I hope this explains the situation well. Thank you so much for your patience. Cheers, Bartek Gatz JIRA Product Manager

            @Susan Griffin - Are you seriously saying that this feature is available only for download instances of JIRA when they already have workarounds to this issue, yet OnDemand STILL can't do anything about the issue? Who on Earth do we need to talk to about this?

            Patrick Driggett added a comment - @Susan Griffin - Are you seriously saying that this feature is available only for download instances of JIRA when they already have workarounds to this issue, yet OnDemand STILL can't do anything about the issue? Who on Earth do we need to talk to about this?

            SusanA added a comment -

            SusanA added a comment - Documentation has been updated: https://confluence.atlassian.com/display/JIRA060/Managing+Users#ManagingUsers-Changingausername

            When JIRA is being used as a User Directory server for other applications (eg Confluence), then by default we don't allow a user rename on the JIRA server as this would not be recognised on the other server.
            The other application would think that user was deleted and a new user was added.

            If you are happy to accept this behaviour, then you can set a flag to allow the rename, as documented in the Knowledge Base article: Cannot rename users despite upgrading/installing JIRA 6

            We are hoping to add the ability to detect renames from a remote Crowd or JIRA server sometime soon, see JRA-32200.
            When this is done, we can remove the above restriction.

            Mark Lassau (Inactive) added a comment - When JIRA is being used as a User Directory server for other applications (eg Confluence), then by default we don't allow a user rename on the JIRA server as this would not be recognised on the other server. The other application would think that user was deleted and a new user was added. If you are happy to accept this behaviour, then you can set a flag to allow the rename, as documented in the Knowledge Base article: Cannot rename users despite upgrading/installing JIRA 6 We are hoping to add the ability to detect renames from a remote Crowd or JIRA server sometime soon, see JRA-32200 . When this is done, we can remove the above restriction.

            SusanA added a comment -

            Hello Nieca, I showed your screencast to our devs and here's what they told me: "The only other reason this might not work for this user is if they have set up their JIRA Internal Directory as a Crowd server for their Confluence users." You can check this by going here: User Management > JIRA User Server. And, yes, I will be reviewing changes to the documentation and updating everything for this feature later today. Sorry it's been so difficult for you.

            SusanA added a comment - Hello Nieca, I showed your screencast to our devs and here's what they told me: "The only other reason this might not work for this user is if they have set up their JIRA Internal Directory as a Crowd server for their Confluence users." You can check this by going here: User Management > JIRA User Server. And, yes, I will be reviewing changes to the documentation and updating everything for this feature later today. Sorry it's been so difficult for you.

            nieca added a comment -

            Dear Susan,

            thank you for explanation and screenshot - everything is understood but see how it looks like at my side - I'm logged as Administrator:
            http://screencast.com/t/7hLf3V9ymaW

            nieca added a comment - Dear Susan, thank you for explanation and screenshot - everything is understood but see how it looks like at my side - I'm logged as Administrator: http://screencast.com/t/7hLf3V9ymaW

            SusanA added a comment - - edited

            See the attached screenshot (above), which shows how to edit the username. Click on the Actions menu.

            SusanA added a comment - - edited See the attached screenshot (above), which shows how to edit the username. Click on the Actions menu.

            SusanA added a comment - - edited

            Hello Nieca,

            Sorry it's been a frustrating experience for you. I am working with the developer to update this section of the documentation, but I wanted to respond to you directly. There are a few cases where this won't work for you, so I just want to make sure you are not in one of these categories:

            • This feature is only available for downloadable instances of JIRA. It is not available in JIRA On Demand.
            • JIRA cannot update external users – for example, users that are coming from an LDAP server or Crowd instance – it can only update users stored in the JIRA Internal Directory. (However, JIRA can update JIRA users stored in an Internal Directory with LDAP authentication.)
            • Only JIRA System Administrators, those with JIRA Administrators global permission who can view users in the database, can perform this function.

            Assuming that none of these limitations apply to you, you should be able to follow this procedure:

            1. Locate the user in the User browser (type g + g and search for User Management) and click their Username. This displays the user's details, below which are several links.
            2. Choose Actions > Edit Details.
            3. Edit the Username.
            4. Click the Update button.

            I hope this helps.

            SusanA added a comment - - edited Hello Nieca, Sorry it's been a frustrating experience for you. I am working with the developer to update this section of the documentation, but I wanted to respond to you directly. There are a few cases where this won't work for you, so I just want to make sure you are not in one of these categories: This feature is only available for downloadable instances of JIRA. It is not available in JIRA On Demand. JIRA cannot update external users – for example, users that are coming from an LDAP server or Crowd instance – it can only update users stored in the JIRA Internal Directory. (However, JIRA can update JIRA users stored in an Internal Directory with LDAP authentication.) Only JIRA System Administrators, those with JIRA Administrators global permission who can view users in the database, can perform this function. Assuming that none of these limitations apply to you, you should be able to follow this procedure: Locate the user in the User browser (type g + g and search for User Management) and click their Username. This displays the user's details, below which are several links. Choose Actions > Edit Details. Edit the Username. Click the Update button. I hope this helps.

            nieca added a comment -

            Thanks Peele,
            but I'm not using LDAP.
            My users are simply in JIRA Internal Directory - how can I rename such user...
            See attached screenshot.

            nieca added a comment - Thanks Peele, but I'm not using LDAP. My users are simply in JIRA Internal Directory - how can I rename such user... See attached screenshot.

            Hi grzegorz.niecka,

            see this page here for more details on renaming users in JIRA 6.0+: How to rename users in JIRA 6.0+ in internal directory with LDAP authentication

            Pelle Kirkeby (Inactive) added a comment - Hi grzegorz.niecka , see this page here for more details on renaming users in JIRA 6.0+: How to rename users in JIRA 6.0+ in internal directory with LDAP authentication

            nieca added a comment - - edited

            Is there a clear explanation how to change/rename user name?
            The documentation is frustratingly poor. It's the only item on the Managing Users page (https://confluence.atlassian.com/display/JIRA/Managing+Users#ManagingUsers-Changingauser'snameoremailaddress) that doesn't actually tell you how to do it, it just says to use the "JIRA Internal Directory"
            The documentation deals with "directiories"...Is there a magic "rename" button or smth?

            nieca added a comment - - edited Is there a clear explanation how to change/rename user name? The documentation is frustratingly poor. It's the only item on the Managing Users page ( https://confluence.atlassian.com/display/JIRA/Managing+Users#ManagingUsers-Changingauser'snameoremailaddress ) that doesn't actually tell you how to do it, it just says to use the "JIRA Internal Directory" The documentation deals with "directiories"...Is there a magic "rename" button or smth?

            Thank you, it turns out there was a configuration set for Bamboo to use JIRA for authentication. This was actually not fully configured or in use so just removing the entry from "JIRA User Server" corrected the issue.

            kbromberger added a comment - Thank you, it turns out there was a configuration set for Bamboo to use JIRA for authentication. This was actually not fully configured or in use so just removing the entry from "JIRA User Server" corrected the issue.

            Hello kbromberger,

            Do you happen to have JIRA being used for user management in other products, e.g. Confluence and fisheye? https://confluence.atlassian.com/pages/viewpage.action?pageId=358908194

            If this does not answer your question, please raise a support request in support.atlassian.com

            Daniel Leng (Inactive) added a comment - Hello kbromberger, Do you happen to have JIRA being used for user management in other products, e.g. Confluence and fisheye? https://confluence.atlassian.com/pages/viewpage.action?pageId=358908194 If this does not answer your question, please raise a support request in support.atlassian.com

            I've updated to 6.0 and when I open Edit Profile for a user I'm only seeing Full Name and Email fields. Is there any other set up that needs to be done to use this? My users are configured in the JIRA Internal directory...

            kbromberger added a comment - I've updated to 6.0 and when I open Edit Profile for a user I'm only seeing Full Name and Email fields. Is there any other set up that needs to be done to use this? My users are configured in the JIRA Internal directory...

            Now... How about those t-shirts?

            Mattias Josefsson added a comment - Now... How about those t-shirts?

            Atlassian: thanks for your work on this issue as well as on v6 as a whole. Great job!

            Chris Simmons added a comment - Atlassian: thanks for your work on this issue as well as on v6 as a whole. Great job!

            bbung added a comment -

            Guten Tag,

            ich bin in der Zeit vom 18.03.2013 bis einschließlich 21.03.2013 nicht erreichbar.

            In dringenden Fällen wenden Sie sich bitte an den zeb/support. Tel. -200

            Mit freundlichem Gruß

            Björn Bung

            bbung added a comment - Guten Tag, ich bin in der Zeit vom 18.03.2013 bis einschließlich 21.03.2013 nicht erreichbar. In dringenden Fällen wenden Sie sich bitte an den zeb/support. Tel. -200 Mit freundlichem Gruß Björn Bung

            comradin, the release of JIRA 6.0 is planned for the second half of May 2013.

            Bartosz Gatz (Inactive) added a comment - comradin , the release of JIRA 6.0 is planned for the second half of May 2013.

              pwyatt Penny Wyatt (On Leave to July 2021)
              8397740ea872 Michael Phillimore-Brown
              Votes:
              786 Vote for this issue
              Watchers:
              404 Start watching this issue

                Created:
                Updated:
                Resolved: