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 ! :--)

I think an extra sentence or two would clear it up. Perhaps: "The current implementation is that new users also use their lower-case username as the user key if it is available. If it is not available then a unique user key that looks like "ID10100" is used instead. The user key is case sensitive".

Thanks for clearing up my misunderstanding. I'm looking forward to not having to warn customers about it being hard to change user names.

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

Jamie,
I hope you do not remove this functionality. I've used it successfully and nothing else comes close to being a viable solution.
Robert

Due to the number of responds and the age of the issue, I'm assuming I have no official solution from Atlassian. I'm running into this class of issue far too often with this Jira product. My SQL is rusty and we are running JIRA standalone (no Confluence) with Active Directories and local users as our means of authentication. Plus I have several custom fields with make use of "User Picker". Renaming a username is not some far fetched task that nobody does. In our case, our company was bought by another company and we are transitioning to their AD services.

It is great to see so many variants of the SQL script documented but I would like to see an application note from Atlassian on this subject. I'm already providing functionality via scriptrunner(groovy), velocity templates and perl scripts, now I have to dust off my sql – I'm NOT IMPRESSED.

Hi Jamie,

what do you plan to remove? The renaming user function? I hope this is a joke, it is so important for us. Please fix the problem with other directories (where DirectoryID is not 1) and maybe also across different directories, but that is not important for me.

Please go on.

Hi Jamie,

important for me to state two things:

• we tested it of course in a development environment - I mean, hey I am working in QA
• when I stated "I have lost my faith in ScriptRunner." I meant of course only related to the renaming of users. We're using the script runner successfully for a few years right now and it saves us plenty of time and work. Great work, go on!

Can't be bothered to look right now but I'm sure that somewhere I've stated that renaming users across directories is not supported. I've certainly never tested that.

Anyway I'll remove this from the next release. Too few people take note of the advice to try on a copy of the production instance. I don't understand why anyone would do such a large operation without testing first but that's the way it seems to be.

@Kai: we use a kerberized Apache as proxy to log into Jira. From Jira's point of view this is just a simple login without Crowd or direct LDAP connection.
I did some tests with the script runner several months ago with mixed results: sometimes it worked, sometimes I got random (Java-) error messages (unfortunately I cannot provide you these anymore). When it worked, the result seemed to be okay & consistent.
However, I do not trust this solution as well because of the random errors.

I also think this must be fixed within Jira itself. Compensating for a low-level design issue by a high-level workaround is in my opinion not acceptable and can never be reliable.

Question to all commenters, who stated that it works fine with the groovy-script-runner: What kind of authentication-setup do you use? Most likely you do not use LDAP->CROWD->JIRA , or am I wrong?

When I (with setup LDAP->CROWD->JIRA) used the script "Renames a user ID" the script completes the job successful, but having a look at the recently changed user reveals folowing:

• field "Username" (viewed in the admin-view) remains still unchanged and furthermore:
  • a JQL-query for "reporter = new.name" shows zero issues ("No matching issues found.")
  • a JQL-query for "reporter = old.name" shows all issues, but additional a warning message ("The value 'old.name' does not exist for the field 'reporter'.")

why I tend to second the comment from Owen Funkhouser above:

I have lost my faith in ScriptRunner.

at least when it comes up to renaming users.

Also using "groovy-script-runner". Working great for use, have probably renamed about 25 user. It also allows you to merge user account which let us clean up all the account we could not rename in the past (we created new accounts instead since we previously could not rename).

Ohh my god is this task old!

But all jira-user (from 3.1.13 and newer) can use the thrid-party-extension named "groovy-script-runner". This plugin is working fine, and don't make any trouble. We are use it since jira 5.0 and has renamed approx 50 users at this time.

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

Agreed, this is frustrating as it seems such a simple request.

I just used the ScriptRunner to merge a user from an old LDAP directory to the new username. It completely corrupted my JIRA v5.0 databse. I am glad I did a backup to XML first.

Can someone post what SQL tables I need to modify change the Assignee and Reporter fields to the new user? I have lost my faith in ScriptRunner.

Note that Crowd does not solve the problem associated with renaming a username.

See https://confluence.atlassian.com/display/CROWD/Adding+a+User: "Username — The user's login name. Within a given directory, the username must be unique. Note that you cannot change the username once the user has been created."

Eric R. Fairhurst is my new running mate.

I think they want to promote Crowd and obviously view this as a dead end and won't fix. I gave up on them fixing this years ago.

Drew Peifer 2012!

Absorb these stats for a second...

Created: 08/Apr/03 7:57 AM

Votes: 639

Watchers: 326

• Agreed, why would userid be a foreign key. It's preposterous. at least passwords aren't stored in plain text though.
• Agreed, in lieu of updating JIRA, a set of official SQL scripts or at least a lits of the offending user tables would be handy, and a show of good faith on Atlassian's side. In fact, the majority of the work for either hotfix solution probably exists within this comment thread
• Agreed, we have all wasted a lot of time and money making JIRA do things that JIRA should already be able to do on its own. Some people have even made money doing this, and they are plugin developers.

Thank you all commenters, for bumping this issue since 2003.

Thank you Atlassian for allowing some plugin developers to make a little money off of this bug.

Seriously though. You should fix it. It's getting annoying.

Even a hacky fix would do for now, like keeping the userid as a back-end foreign key but duplicating that value as an editable attribute (displayname? newname? get-users-off-our-backs-ID? who cares), then changing visual templates so you're displaying that new attribute where userid is currently being displayed (if we can do a find and replace, why can't you guys? keep your DB schema, just change the visual templates so we're looking at AND EDITING a different attribute of the user object).

We don't care how messy your code is, we care how messy our JIRA instances are, and they're getting messy. Since you guys are closed-source, it shouldn't matter what black magic you do on the back-end. Just give the users what they want and close this bug. It's killin me, smalls.

When will this issue be fixed?

facepalm - this issue can't be open since 2003. Even Microsoft can handle username changes meanwhile.

As usual basic functionality has to be implemented by customers. For PostgreSQL here is a procedure that does the account renaming:
https://gist.github.com/2352960 (patches and beers are welcome).

Hi Atlassian,

Could you please confirm this feature is include in JIRA 5.1 ?

Regards,
Sven.

Thanks Chad, I will definitely check it out. Looks like I might be able to use some of the workflow enhancements as well.

If you install the script runner plugin for JIRA, it provides an inbuilt script to rename users. I've been using it for about a year, and it works really well.

To Atlassian

The fact that one of your customers was so fed up with your poor workmanship that they built a kludge and shared it with all of us does not free you from the obligation of actually fixing your software.

FWIW, I recently undertook a username renaming exercise, choosing the route of backing up to XML, editing the XML, then restoring from the edited XML.

To do the renaming I created a perl script that used regexps on all known expressions where usernames were found to be used as keys. This was to avoid the problem of collateral renaming damage. The list of keywords was derived empirically by analyzing everywhere that a username was found. WARNING: The list is probably not exhaustive, and seems to be based on the extent of activities and workflows you have in your JIRA.

#    name="fred"
#    userName="fred"
#    username="fred"
#    lowerUserName="fred"
#    assignee="fred"
#    author="fred"
#    caller="fred"
#    childName="fred"
#    lowerChildName="fred"
#    entityId="fred"
#    lead="fred"
#    newvalue="fred"
#    oldvalue="fred"
#    reporter="fred"
#    roletypeparameter="fred"
#    updateauthor="fred"
#    
#    <meta name="jira.update.author.name">fred</meta>

A big caveat you should be aware of concerns the <ExternalEntity> entries. Unknowingly, I had external entity entries with the same name as usernames I was renaming to. This resulted in duplicate (non-unique) external entity names after the perl script had run. Eg:

<ExternalEntity id="10" name="fred" type="com.atlassian.jira.user.OfbizExternalEntityStore"/>
[...]
<ExternalEntity id="515" name="fred" type="com.atlassian.jira.user.OfbizExternalEntityStore"/>

This caused JIRA to crash. You must ensure that your renaming does not result in duplicate names in the ExternalEntity and User entry lists.

Apart from that, the script worked fine for my installation, but there are no guarantees. USE AT YOUR OWN RISK. Keep a copy of your original unedited backup/export XML and if things go pear-shaped just restore from that.

#!/usr/bin/perl -i~
#
# Edits file in-place changing all known JIRA keys that contain
# usernames from oldvalue to newvalue. Run it against an XML backup file "entities.xml".
# Original file is preserved as "entities.xml~".
#
# Example: % jira-rename-user.pl fred:fblogs nick:ngianniot entities.xml
#
# BE CAREFUL: DO NOT CREATE ANY DUPLICATES IN THE <ExternalEntity> section!!!!!

use warnings;

$USAGE = "usage: $0 from-username:to-username [...] file\n";

while (@ARGV > 1)
{
    $from_to = shift;
    (($from, $to) = split(/:/, $from_to)) == 2 or die "bad from:to arg [$from_to]\n";
    push(@pairs, [$from, lc($to)]);
}

@pairs > 0 or die $USAGE;

foreach $pair (@pairs)
{
    my ($from, $to) = @{$pair};
    print "from=[$from] to=[$to]\n";
}

print "file=[@ARGV]\n";

@keys = qw(
name
userName
username
lowerUserName
assignee
author
caller
childName
lowerChildName
entityId
lead
newvalue
oldvalue
reporter
roletypeparameter
updateauthor
);

while (<>)
{
    foreach $pair (@pairs)
    {
	my ($from, $to) = @{$pair};

	foreach $k (@keys)
	{
	    s|\b$k="$from"|$k="$to"|g;
	}
	
	s|<meta name="jira.update.author.name">$from</meta>|<meta name="jira.update.author.name">$to</meta>|g;
    }	
    print;
}

We have utilized the SQL scripts across multiple clients several times. You need to be proficient in SQL and have experience working with JIRA. However, if you have at minimum an adequate database person and a solid development environment then there is nothing to fear with this.

I think that it is important to remember: If you have any custom fields or other customisations, then the plugins, scripts and SQL snippets are not going to fix all your problems and you are very likely to sit with a system that needs to be restored from backup. This is not a task that presently can be attempted with a "hope it works" attitude.

Where could we find a list of tables in MSSQL that need updating in order to rename/merge user accounts in Jira 4.4.3?

Don't worry, Atlassian, you don't have to come up with a kludge to fix this because someone else already did!

Everyone, check out the script runner plugin. It has inbuilt scripts, and one of my favorite is "Rename user", which also lets you merge users!

(I love this ecosystem that sprang up around fixing Atlassian's inadequacies. It's like a construction project that frequently leaves holes where windows should be and occasionally just throws up a fireman's pole in lieu of stairs. But you can build steps yourself! So who cares?)

+1 on the above comment. We recently tried to merge users, and it was not a pretty sight. Atlassian, the hole is getting deeper....

Merge users capability

In addition to ability to rename a user we need to be able to merge accounts. This is quite a similar requirement but a little different as two entities get combined. It has become more important with ldap support as new user accounts are created automatically so won't be intercepted in the old process.

When a user name changes in the external directory (typically by marriage) we need to be able to replace the user id in assignee, reporter, watcher, rights, ownerships, filters etc with the new user id. Our user will have probably logged in with the new account and may have even done some work - you never know - so we will need to merge rather simply renaming.

here is the script I used for MSSQL db. One thing to note is to make sure that the new name does not already exist in jiraschema.external_entities. We use LDAP and it had already pulled in the new user name and cause errors since the rename causes an duplicate record. Also jiraschema.userhistoryitem caused some issue, not sure how it got resolved... i messed with it a bit and not sure how that got renamed

update jiraschema.changegroup set AUTHOR='newusername' where CAST(AUTHOR AS nvarchar(max))='oldusername'
update jiraschema.changeitem set OLDVALUE='newusername' where CAST(OLDVALUE AS nvarchar(max))='oldusername'
update jiraschema.changeitem set NEWVALUE='newusername' where CAST(NEWVALUE AS nvarchar(max))='oldusername'
update jiraschema.columnlayout set username='newusername' where CAST(username AS nvarchar(max))='oldusername'
update jiraschema.component set LEAD='newusername' where CAST(LEAD AS nvarchar(max))='oldusername'
update jiraschema.external_entities set NAME='newusername' where CAST(NAME AS nvarchar(max))='oldusername'
update jiraschema.favouriteassociations set USERNAME='newusername' where CAST(USERNAME AS nvarchar(max))='oldusername'
update jiraschema.fileattachment set author='newusername' where CAST(author AS nvarchar(max))='oldusername'
update jiraschema.filtersubscription set username='newusername' where CAST(username AS nvarchar(max))='oldusername'
update jiraschema.jiraaction set AUTHOR='newusername' where CAST(AUTHOR AS nvarchar(max))='oldusername'
update jiraschema.jiraaction set UPDATEAUTHOR='newusername' where CAST(UPDATEAUTHOR AS nvarchar(max))='oldusername'
update jiraschema.jiraissue set reporter='newusername' where CAST(reporter AS nvarchar(max))='oldusername'
update jiraschema.jiraissue set assignee='newusername' where CAST(assignee AS nvarchar(max))='oldusername'
update jiraschema.jiraworkflows set creatorname='newusername' where CAST(creatorname AS nvarchar(max))='oldusername'
update jiraschema.membershipbase set USER_NAME='newusername' where CAST(USER_NAME AS nvarchar(max))='oldusername'
update jiraschema.OS_CURRENTSTEP set owner='newusername' where CAST(owner AS nvarchar(max))='oldusername'
update jiraschema.OS_CURRENTSTEP set caller='newusername' where CAST(caller AS nvarchar(max))='oldusername'
update jiraschema.OS_HISTORYSTEP set owner='newusername' where CAST(owner AS nvarchar(max))='oldusername'
update jiraschema.OS_HISTORYSTEP set caller='newusername' where CAST(caller AS nvarchar(max))='oldusername'
update jiraschema.portalpage set  username='newusername' where CAST(username AS nvarchar(max))='oldusername'
update jiraschema.project set lead='newusername' where CAST(lead AS nvarchar(max))='oldusername'
update jiraschema.projectroleactor set roletypeparameter='newusername' where CAST(roletypeparameter AS nvarchar(max))='oldusername' and roletype='atlassian-user-role-actor';
update jiraschema.schemepermissions set perm_parameter='newusername' where CAST(perm_parameter AS nvarchar(max))='oldusername' and perm_type='user';
update jiraschema.searchrequest set authorname='newusername' where CAST(authorname AS nvarchar(max))='oldusername'
update jiraschema.searchrequest set username='newusername' where CAST(username AS nvarchar(max))='oldusername'
update jiraschema.trustedapp set CREATED_BY='newusername' where CAST(CREATED_BY AS nvarchar(max))='oldusername'
update jiraschema.trustedapp set UPDATED_BY='newusername' where CAST(UPDATED_BY AS nvarchar(max))='oldusername'
update jiraschema.userassociation set SOURCE_NAME='newusername' where CAST(SOURCE_NAME AS nvarchar(max))='oldusername'
update jiraschema.userbase set username='newusername' where CAST(username AS nvarchar(max))='oldusername'
update jiraschema.worklog set author='newusername' where CAST(author AS nvarchar(max))='oldusername'
update jiraschema.worklog set updateauthor='newusername' where CAST(updateauthor AS nvarchar(max))='oldusername'
update jiraschema.customfieldvalue set stringvalue='newusername' where CAST(stringvalue AS nvarchar(max))='oldusername'
update jiraschema.userhistoryitem set username='newusername' where CAST(username AS nvarchar(max))='oldusername'

cwd_user was introduced by embedded crowd for user management in Jira 4.3, and isn't in previous installations. AFAIK the problem still exists, cwd_user is just yet another table that has to be updated when you rename a user. I suspect the introduction of crowd into Jira is the first step in properly fixing this problem.