-
Suggestion
-
Resolution: Unresolved
-
None
-
61
-
44
-
NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.
If public signup is enabled, it's likely to have multiple usernames for the same user. To merge their data, you could run sql to change usernames, but you cant merge usernames on the users table because you'll get a duplicate key violation. Therefore you'd need a script to detect an existing username, query the duplicates group associations, associate the duplicate's groups to the primary's user ID, and then remove the duplicate.
This is different from a request to match internal with external user IDs, http://jira.atlassian.com/browse/CONF-10654 .
Note that implementing this will also have to take into account what to do with existing user content, mentions of affected users, and their user settings (including profile picture, preferred language, timezone, notification configuration and watches).
- incorporates
-
- Closed
- is duplicated by
-
- Closed
-
- Closed
- is related to
-
- Gathering Interest
-
- Gathering Interest
-
ADM-130984 Loading...
- relates to
-
- Gathering Interest
- mentioned in
-
-
-
-
-
-
-
-
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[CONFSERVER-11990] Ability to merge usernames
Yea...this seems like a pretty "low hanging fruit" in terms of a feature that should get added to the base configuration of Atlassian products...not just Confluence.
I cannot believe that this is an issue and feature request for twelve years now. The guide that Atlassian has provided contains SQL queries but many can not be executed as they fail with duplicate entry erros due to unique entry constraints.
If you are connecting to Active Directory (others?) there is a unique user guid that persists across username changes that would allow automatic painless name changes if the guid is stored in crowd. There would still need a manual merge process for people that are outside that process.
Michael Brown
added a comment - I was told to add my scenario here as well by Atlassian support. We currently use JIRA 6.2 for user management for our confluence 5.4.3 installation. We changed usernames in JIRA and switched to LDAP. It appears that confluence did not detect the name changes for all the users. Now when some users login, they are treated as a new user. They have lost their profile info, personal spaces. Any pages created with the original user account now show up as "Unknown User". Turns out that Confluence since 5.3 use an unique hash to identify users rather than their username, that is the reason behind users not being able to retrieve their content just by having the exact same name. To fix this i have to run a bunch of queries and siync user names with their user keys. Not so fun when you have about 10 users that got orphaned.
Michael Brown
added a comment - I was told to add my scenario here as well by Atlassian support. We currently use JIRA 6.2 for user management for our confluence 5.4.3 installation. We changed usernames in JIRA and switched to LDAP. It appears that confluence did not detect the name changes for all the users. Now when some users login, they are treated as a new user. They have lost their profile info, personal spaces. Any pages created with the original user account now show up as "Unknown User". Turns out that Confluence since 5.3 use an unique hash to identify users rather than their username, that is the reason behind users not being able to retrieve their content just by having the exact same name. To fix this i have to run a bunch of queries and siync user names with their user keys. Not so fun when you have about 10 users that got orphaned. 
Susan Hazlett
added a comment - There are numerous comments on https://jira.atlassian.com/browse/CONF-4063 that refer to merging users in a number of different scenarios, not just public signup (although another good example of the problem). We migrated from OnDemand to installed version, and are using our Active Directory and Crowd for SSO and authentication. The users migrated from OnDemand didn't always have the same username, so we had several users with content that is lost to them. CONF-4063 should also be referenced here so that the myriad comments are not lost as to the importance of this ability in a corporate/enterprise environment.
Susan Hazlett
added a comment - There are numerous comments on https://jira.atlassian.com/browse/CONF-4063 that refer to merging users in a number of different scenarios, not just public signup (although another good example of the problem). We migrated from OnDemand to installed version, and are using our Active Directory and Crowd for SSO and authentication. The users migrated from OnDemand didn't always have the same username, so we had several users with content that is lost to them. CONF-4063 should also be referenced here so that the myriad comments are not lost as to the importance of this ability in a corporate/enterprise environment. An automated ldap login that creates accounts typically require a merge capability. It is practically impossible to prevent users from logging in and creating a new account after they have had a name change.
Ahahahahahaha