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

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?

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!

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?

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.

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.

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.

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.

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?

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.

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?

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,

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.

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.

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

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

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

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

@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?

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.

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.

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

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

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.

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

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.

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...

Now... How about those t-shirts?

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

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.

Hello,

is there a timeframe when jira 6.0 will be realeased? we are struggling with the renaming problem and it is a major pain..

I would be happy to see this one working as well.

tm2, glad someone remembered! However, we are going to make sure that we do not celebrate #11. For those Spinal Tap fans out there, "This one will NOT go to 11..."

Okay, I am a little bit late...

BUT: HAPPY BIRTHDAY to the 10th years anniversary! ;o)

Thanks Mark, for your extra reply, it is clear now.
Good Job done for the version 6.0-m10 !

I'm working now how to script a change of 18 000 users on an instance using JIRA DIRECTORY LINK (with confluence too), some happy time in perspective ! :--)

That document says "Existing users will get allocated a key that is equal to the lowercase of the username."

I guess I can see some room for ambiguity.
Would you suggest I try to reword that sentence, or just add some further information somewhere?

So I guess the user key is either random for new users or some hash of the username, and then if there is a conflict then some other user key is chosen.

Current implementation is that new users also get lower-case username as the key if it is available.
If it is already taken then they get a userkey that looks like "ID10100" where the numeric part is based on the numeric ID of the DB row.
(Note that this is guaranteed unique even in the face of some crazy username like "ID10100" because the lower-case of that is "id10100" and userkey is case-sensitive).
If you are interested in seeing this - download the EAP and check out the contents of the "APP_USER" DB table.

Glad to hear it! I went back and read the description in your document at https://developer.atlassian.com/display/JIRADEV/Renamable+Users+in+JIRA+6.0
and I think I see where the confusion came from. That document says "Existing users will get allocated a key that is equal to the lowercase of the username."
but you said that a brand new user that would usually have the same key ("bob") can be added. So I guess the user key is either random for new users or some hash of the username, and then if there is a conflict then some other user key is chosen. Is that closer to correct? It might be worth pointing this out in the document.

~Matt

Please tell me if I've misunderstood how this is working behind the scenes.

You've misunderstood how this is working

If you nename a user "bob" to "newbob", then you can rename "bobby" to "bob" (or create a brand new user called "bob").

Your confusion may come from the fact that we use a character-based "userkey" that looks much like the username as the primary key for users (rather than a numeric ID).
This is a little unfortunate, but was the fastest and least disruptive way to change 10 years worth of code.

I'm hoping the docs will make it clear that this is implemented as supporting aliases for users. I can't rename a user to any user name that has ever existed, right? That is once I create a user "bob", I can create an alias "newbob" and that will work fine. But if I wanted to rename a user "bobby" to "bob" I can't do that because there is already a "renamed" user bob. Please tell me if I've misunderstood how this is working behind the scenes.

I just finish doing an update of our JIRA server to add LDAP authentication. We have users that were created on this instance that have no LDAP name in the directory so after doing the move to LDAP, which with JIRA is an all or nothing scenario, I had to move as list of users that were not in LDAP back to the jira internal directory. In case anyone is interested in how to do this I used the following scripts which reads from a file on the server with all the names in it on separate lines. (note if you create the list in windows make sure you run dos2unix on the list file before running the script)
The script to move users is for POSTGRES.

#!/bin/sh
database='jira_525'
file='FH-user-fixes6.csv'

 for line in $(cat $file)

 do 
	echo "moving  user to internal JIRA directory:- $line"
	echo "line = $line"
	psql $database -c "update cwd_user set directory_id=1 where user_name='$line';"
	psql $database -c "update cwd_user_attributes set directory_id=1 where user_id in (select id from cwd_user where user_name='$line');" 
	psql $database -c "update cwd_membership set directory_id=1 where child_name='$line';" 
done

Now You also need to reset the passwords on the users you move back to they can go in and change it the first time they login, thus the script to set passwords to "admin" on all the users I moved back (200 + users)

#!/bin/sh
############################
#  Script to change the passord of a set of users read from a file, to 'admin' and set the login to make them change the password the first time they login.
#  NOTE: encrypted string below is admin for the password
 
database='jira_525'
file='FH-user-fixes6.csv'
encrypted_password='{PKCS5S2}nOOgUxX7NDZjPCyLV5moFDHuPnYgEogXUfit3LB97wdtzSZt7d8E0CrRTgHI22/Y'

for line in $(cat $file)
do
	echo "update password for user: $line"
	psql $database -c "update cwd_user set credential='$encrypted_password' where user_name='$line'"
done

With this done we realized that we had users we had tested against LDAP which though they matched up, where not the same user as the internal JIRA user (which was now in LDAP). and there is were the ability to change user names would saved me about 6 hours work.

I ended up having to move the 110 users I found that were wrong back to the Internal Directory so they could continue to use JIRA.

You say you are working on this.
We have about two users that have ldap accounts that we would like to move back into LDAP (Of course because you have no solution for moving a single user between directories I would use the same scripts mentioned above to change the directory. (after using you new feature to rename them.) If this feature is not available for a year that means I have to spend between 10 and 20 minutes on each users to move them to a new user.

In the threads below if fails to mention filters that need to have names changed, Dashboards, and of course if the user has private filters and Dashboards, you need to have him share them before you as the administrator can move them.

All in all a very painful and time consuming task.

I look forward to seeing the new change user feature in Jira.
And hope the code above may help others that are struggling through the same issues.

Thanks.

I've uploaded new version of sql script where I've added next table (projectroleactor) which wasn't considered before.

Hi Mark,

Let me do a feedback on my issue start of next week.

Regards,
Sven.

mlist.cib.aps.transversal.applications.london
There will be a current number of orphan items in EAP 8 (6.0-m8) because we are still working on fixing some parts of the system.
EAP 9 should be available for download next week.
There will still be a few parts not complete in EAP 9 and even EAP 10!
(Undoing 10 years of using the username as a foreign key has been quite a long journey)

That said, we have tried to cover most the common parts of JIRA first, so it is also possible that you are experiencing bugs in subsystems that we thought we had finished work on.
If you wish to list all orphan objects, then I can double-check that they are all known.

... there will some orphan items (history etc ...)

You mean the Change History as seen on the View Issue page?
This work is done and it looks to me like it works fine in 6.0-m8.
If this is the "history" that you mean, then I would appreciate some detailed steps to reproduce.

Hi Mark,

I did some test with the current beta 8.
Follow my understanding :
if I have got a username A and I rename as B, there will some orphan items (history etc ...) ?
and I have got a username C and I rename as A, this new A user will inherit all orphan item for the old username A, it is correct ?

Regards,
Sven.

Thank you for your response! I will vote and watch the new issues!

sko , david.samuelsson

For LDAP synchronization, is there an option to specify user-id and user-name seperately?

Firstly I need to point out that in v6.0 rename user will only work for locally stored users.
This means that admins can manually edit user names in an "Internal Directory" and the "Internal with LDAP Auth" directory but we cannot detect remote changes from the "MS Active Directory", "LDAP" or "Crowd" user directories.
I have raised JRA-32199 and JRA-32200, and we are keen to work on them soon, but we just ran out of time in v6.0.

The reuse of the shortcut leads to the problem, that a new employee inherits the rights, tickets, ... of the old employee

That is correct, and that is by design.
We use the "login" or "username" as a natural key to match accounts that should be treated as signifying the same person/user.
In most cases this is desired behaviour, eg you start using JIRA with local users, but later on you want to connect to an LDAP server. In this case the "jbloggs" account in LDAP should be treated as the same user as the "jbloggs" account that was stored locally.
What you want is a solution to JRA-11926 - further questions and comments are better placed there as this issues is already chock-full and will be marked as resolved when 6.0 is released.

However, I also believe that at least 6.0 will give you a better workaround to your current one:

• You should have an active internal directory sitting higher than your LDAP directory.
• When a user leaves the company, manually create a user entry with the given username.
• Rename this local user eg from "abc" to "old_abc" or whatever
  If an LDAP user with name "abc" still exists, then you have now have 2 separate users - "abc" (LDAP) and "old_abc" (local)
  (I would also mark this account as Inactive)
• The LDAP user with username "abc" will now be treated as a new user who owns no existing object.
  As a bonus the old account still has the correct Full Name and email address of the previous user and the inactive flag as a reminder.
  But please note that the existing EAP has a bug that stops this from working - it is fixed in the code and will ship in a future EAP release.

I'm very happy that Atlassian decided to add "Rename Username" feature in JIRA 6.0. Good job.
But by the time when stable release is available we need to use SQL script. So I've prepared SQL script for Postgresql database (without "join" syntax) which was based on existing one. Additionally I've added a few tables which were not considered (avatar,notificationinstance,remembertoken).

I can confirm the same issue as Steve. We have 5 letters that gets reused, we have around 20-70 people / month that needs to be removed and handled, thus we are not any small organization.

We have built our own in-house application to handle this.

We do the same, we merge all account info to an "inactive_<insert_username>" and transfer all associated dependencies to it.

Hey guys,
this sounds great.

But I think there might be still a problem (maybe only for our organisation):
In our organisation every user has a shortcut of 3 characters as login. When an user leaves the organisation, his shortcut can be reused for a new employee (user). The users are generated/synchronized through the LDAP connection. The reuse of the shortcut leads to the problem, that a new employee inherits the rights, tickets, ... of the old employee, because user-id and user-logon-name are the same. We are using the Script Runner to merge old employees on one extra account to avoid the problem of inheriting.

After reading your release notes, I'm not sure, that this problem is addressed, too?

• Is this problem not really a problem (have I missed something)?
• For LDAP synchronization, is there an option to specify user-id and user-name seperately?
• How to merge existing users that should have id (internal id) / shortcut (login) but currently have shortcut/shortcut?
  • login-id (=name) and internal id is currently kind of "abc"
  • the new construction is seperated: login-name = "abc" and internal user-id = "1111"

Thanks!

Well done guys !!!

Well done! http://www.youtube.com/watch?v=78O7ON7V1Ik

This is amazing news. Late, but still amazing. Looking forwards to a few more free weekends i don't have to spend re-indexing jira.

As mentioned in the updated description of this issue, we targeted rename user as one of the top voted issues we wanted to attack next.

Well, now you can see the work-in-progress for Rename User in JIRA 6 Early Access Program (EAP) release 4:

• Read the release notes
• Download the EAP release
• If you're a plugin developer, read the updates you may need to make

The team is hard at work getting this ready to ship (i.e. there is still work to be done, and what you see in EAP 4 is not the complete solution). Thanks again for your patience and your feedback.

Added a few tables that didn't seem to appear in older SQL versions people uploaded.

refer you to this comment and the one directly under it
https://jira.atlassian.com/browse/JRA-1549?focusedCommentId=265829&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-265829

Wow, just got started and was shocked at this incredibly poor design decision. Why use username as a key? You already have an ID field you can use for keying on the cwd_user table. I'm guessing this big mistake just got baked in over time. Very poor normalization.

jfireham, that's a great catch. I've corrected that page.

Bulk changing reporter and assigne also works in jira prior 5.2.
This will end in 2 users (old, new) because of comments you can't delete the old username.

It doesn't change any comments, filters, dashboards, notifications, watchlist, etc.

https://confluence.atlassian.com/pages/viewpage.action?pageId=298979005 seems to imply that in 5.2 you can change a username. But I see nothing in the release notes.

"JRA-1549: for when you think that JRA-9 was rushed into production."

(for those of you unfamiliar with the context: https://jira.atlassian.com/browse/JRA-9. It went nine years.)

+1: 10th Birthday T-shirt for the 10 year old bug. Your running out of stock on these anyway: http://www.ptxstore.com/atlassian/product_info.php?products_id=871

In seriousness though, I understand that JIRA came from a developer environment, having used it for most of these 10 years at different companies, and that you have workarounds for this. I also understand the growing pains you are going through as you bring this up to the level that true business' administration rules require. Hopefully you are approaching critical mass with many of these basic features, especially to also support OnDemand, to allow them to all be fixed at once.

+1. The T-Shirt is the best update I have seen in this issue all these years.

+1 TShirt
JIRA : Just Ignore Renaming Anyone (Anything, Any user)

"This T-Shit is to comemorait a dekade of JRA-4195."

+1 T-Shirt

+1 T-Shirt !

+1 T-Shirt - JIRA: Justifiably Insane Renamed Asylum

+1 T-Shirt for me.

are you kidding me? we are using a bugtracking system to improve our system and fix bugs faster and the system itself has a major "10Years-Bug"...
where cann I buy these shirts? Fix it please!

Ha - I totally need one of those!

The t-shirt idea is fantastic.

We should have t-shirts made for the 10-year anniversary of this issue and misspell Atlassian on them. "Sorry, there's no way to change the shirts once they're printed. But you can work around it with some masking tape and a marker."

The positive thing is that it's going to be fixed in the next 11 months (probably).

@Max Newbold: The problem is there's no userID, only the username

In other news, I just noticed that this bug about 95 days away from its 10-year anniversary...

Now where's the Like button when I really need it.... Well said, J Fire.

The only reason I can think of why this should be a hard thing is that ages ago, someone at Atlassian made the mistake of using the username string as a foreign key, instead of a user ID that nobody really sees or cares about. Anything user visible or user interactable (like username, email address, name, favorite color, etc.) should be easily changeable.

Dear Atlassian:

Instead of adding new features that most rarely use, do this:

• Change your entity model.
• Provide a database upgrade script. You do not need to maintain schema compatibility. We all backup our databases prior to upgrading anyway.
• Provide a supported script that will change a username for existing releases.

Please. This is what grown-ups do.

I got a request from a customer user last week who got divorced.

I just had a request from a user to change their username because they got married, but I can't... I don't have time to mess around with scripts. We got JIRA to save time not be a maintenance nightmare. Get this fixed Atlassian.

Ouch! About the best you can do is to create a spreadsheet of existing userid and the desired userid. Then create a script to generate the dozen or so SQL statements needed for each userid change. Don't forget the contents of user-based custom fields. Test it all in staging. This won't fix references to old userids in comments, but everything else changes. The hardest bit is gathering all the new userids I find.

I wish I would have known this wasn't possible when we first started using JIRA. We let people sign themselves up, and now have a wide variety of usernames, from email addresses, to full names (including spaces) thanks to the Pivotal Tracker importer tool. Now the workaround is going to be quite a hassle, or we're stuck forever with a bunch of crazy usernames everywhere.

Need this feature for the Google Apps integration.

https://confluence.atlassian.com/display/JIRA/Changing+Usernames+in+JIRA

@Richard Bone: Sorry, but I guess here is not the best place to submit you bug or post this comment. Neither Jira 5.07 nor any other version have got a built-in script to rename a userID.

I'm pretty sure your built-in script comes from the Script Runner plugin (aka Groovy Runner) and the right place to post your comment or submit your bug is here: https://studio.plugins.atlassian.com/browse/GRV (the issue tracker of the Script Runner plugin).

JIRA 5.0.7 has a built-in script runner to rename a userID. Before running the script, users can preview a list of all the changes to be made. After running the script, found that the new user ID was not associated with any groups. See JRA-30596 for details.

At the risk of repetitive begging:

Would anyone be willing to post the change username SQL s/he is using for jira 5.x?