How to recover user's revision history, etc. after a name change in LDAP?

[Fred Bunting]

When a user changes their login name (e.g. because they got married), we would like to preserve that user's old revision history.  (Mentions and watches would also be nice, but not as important.  And preserving their old Personal Space would also be preferable, although currently the workaround is to create a new Personal Space, and move the contents of their old Personal Space into it.)

According to Confluence 5.3 Release Notes, if a user's name changes in an external LDAP directory, then "Confluence will automatically detect the renamed user."  (It does not say how it does this – i.e. how does it know the old and new names in the LDAP directory are related?)

Specifically, in the Mentions and page history section under Notes at the bottom of the page, "Any user mentions in current pages will automatically reflect the user's new username, but any mentions in page versions created prior to Confluence 5.3 will include the user's old username."

However, this does not appear to be true.  Even for page revisions (versions) created after we upgraded from Confluence 5.1 to 5.5 a year ago, the user's revisions appear under their old login name (now an "Unknown user").

In other words, the new LDAP account appears as if it is a completely brand new user, and the old account is simply gone from the directory (an "Unknown user").  There appears to be no connection whatsoever between the old and new accounts.

---

Update: Perhaps a rephrasing might help.  The ability to Change usernames came in Confluence 5.3, and is described in the Confluence 5.3 Release Notes.  For instances like ours, where we manage our users in an external LDAP directory, all it says is that "Confluence will detect the changes."   How is that supposed to work?  Is there something special we need to do in that LDAP directory to associate the old username with the new one?

[Mike Rathwell]

Fred,

I went through exactly the same thing you did and had the same needs/concerns you have. Exactly. I suspect the kind of thing you're seeing and would like to correct (among other things) is what might be at the top of a confluence space/page like "Created by unknown user <oldusername> and updated by <newusername>" (paraphrasing there).

There isn't any (as I far as I could find) "approved" method for doing what you need to do and, in fact, when proposed to Atlassian they did say "this isn't an approved method" but go for it and YMMV. So... here is what I did to get around some of that. I really suggest you do this on a dev box first to see what happens and any scripts that cause Something Bad to happen won't kill your production system as it involves rooting around directly in the Confluence database.

All is not lost; Confluence doesn't throw away the old users; they just become unknown because there isn't an authority for it to validate them and they still exist in the Confluence DB as actual usernames. The first step is the hugely manual one.

1. The table user_mapping has all the usernames that ever got created to work with Confluence both the old ones and the new ones. There are 3 fields in the table; user_key, username, lower_username. First big ugly manual step is to mate the "old" username with the "new" username so you have the user_key values for both the old AD name and the new AD name associated with a specific user.
2. Where you go from here, now, is to find all the places these user_key values exist and replace the old with the new. This isn't an exhaustive list (as I am going somewhat by memory and trolling the DB as I write this)
   1. content table - replace "creator" and "lastmodifier" old user_key with new user_key
   2. content_label table - replace "owner" old user_key with new user_key
   3. content_perm table - replace "username", "creator", and "lastmodifer" old user_key with new user_key
   4. At this point, you can see where I am going with this and it's obvious which fields in which table to update old with new (but always leave the new values alone). As such other tables that, in trolling the database, these values are found include:
      1. likes
      2. links
      3. notifications
      4. pagetemplates
      5. spacepermissions
      6. spaces

I've probably missed some tables to fix but this should solve most of the "unknown" user and history stuff for you.

Good luck.

mike

P.S.: It would likely be safest if you stopped tomcat before embarking on this extravaganza but I made changes "hot" and nothing Bad happened. Maybe I was just lucky.....

P.P.S: I think there is an improvement request at Atlassian (Atlassian wizards pls comment) that adds the functionality to the Administration tools that would allow an admin to point at one userid and reassign everything (or selection of stuff) from one user to another. I hope that gets in.

[Fred Bunting]

Mike, excellent info, thanks! Doing some manual editing of the database (which I would prefer to do with the the instance offline) would be a last resort. Currently, this only affects one user, so I can't justify doing this. But it's good to know.