Can we change the name in Cloud version too.

In a corporate scenario with and external AD/LDAP directory, a user would get married (etc), get an external name change pushed by HR processes likely automatically, but asynchronously. At some point they would login to Confluence and get a new local account since Crowd doesn't attach the external account to an external invariant like the AD user GUID. It's going to be approximately impossible to guarantee that the Confluence ID is changed when the external ID is changed. So name change without merge capability won't get the job done.

A number of the comments on this issue refer to the ability to merge two separate user accounts with content. This can be discussed and tracked separately on CONF-11990.

We are pleased to announce this will be fixed in the upcoming Confluence 5.3 release due out shortly.

Glad to hear that this will be addressed in Confluence 5.2!
At our location, we switched from LDAP to Active Directory when our company got bought. All users who were here when we were bought have two accounts, with content associated with both authentication mechanisms.

Will we be able to merge user accounts? Or does this only allow for a rename of a user account if the new account doesn't have any content associated with it?

I would even be happy with a simple way to reassign comments so I can delete a user and create a new one.
I don't want to lose comments by a user - why can they not simply stay in system and keep their original commenter name, even of that user no longer exists?

A definite is that we will support a local user rename.

So if we delivered this bare minimum then in the case where an LDAP/Crowd/JIRA managed user was renamed you would then manually via the GUI (or script it via the remote API) change the username in Confluence to match. This is a straight replacement to our current "offering" of running lots of scripts

What we are actually hoping to deliver at the same time however is the detection of renames in an LDAP directory which will remove the need for the manual step. We are likely to deliver this in Confluence 5.3 but it is dependent on other development teams within Atlassian so I can't offer a guarantee yet.

Further down the line we should be offering the same detection for Crowd managed users but this is unlikely to be ready in time for Confluence 5.3.

good to hear this issue is addressed in future releases!

Confluence 5.2-m19 EAP discussion:
https://confluence.atlassian.com/display/DOC/Confluence+5.2-m19+EAP+Release+Notes

Merging content for duplicate accounts is indeed the most painful issue. I have close to 1,000 duplicate accounts on one Confluence instance because of a switch to LDAP (many people previously using local accounts got a new one once authenticated via LDAP), and I bet many others have the same issue. It's not trivial because you can't always predict what to do and develop a user-friendly conflict resolution interface (e.g. à la Apple when you have conflicts in your contacts or agendas) is a serious task (the lazy solution would be to ask users to migrate content manually and just delete/deactivate their old account).

In the ldap, a common circumstance would be
1. ldap user (v1) logs into Confluence and gets a local Confluence ID.
2. ldap user gets married (etc) and changes login name and display name
3. ldap user (v2) logs into Confluence using new ID (or, is logged in automatically by SSO) and generates a new Confluence ID.
4. User has two separate IDs, current and historical

In this situation, we really want to be able MERGE the two IDs than rename an ID. This might be seem semantic, but we really need to be able to change all reference to the old account to match a new one even if it exists or we don't have a solution.

===

In the case of Active Directory the ideal solution would be to read the user's objectGUID into the Confluence directory as an invariant object attribute. This 128bit AD attribute is unique not just in that Active Directory but in the universe and persists for the life of the AD object. What more could you possibly want! AD has its problems but the use of GUIDs really works brilliantly in identity management and provides a high level of reliability across renames.

When a user logs in with a new name but with a known GUID, the account could actually be automatically renamed using the new source name attributes. Maybe a checkbox to authorise AD as a The Source of Truth for identities and permit automatic renames might allay fears, but this is what should happen, seamlessly. Doing anything else - that is, what some generalized GUIDless-multidirectory safe might process require - constitutes integration failure. I don't know your numbers, but I would expect that Confluence with a single external AD constitutes a significant chunk of your ldap installations so this option would be kill a lot of birds with a single stone.

AFAICS the exception condition where an attempt to rename clashes with an existing name should actually halt and produce an exception report. In the above scenario it should never happen but if it does the solution will likely require some thinking, reconfiguration and/or changes outside Confluence.

This doesn't solve the myriad of problems that can arise with multiple directories that don't have unique persistent identifiers but a configuration that supports this approach should form a part of the solution.