Personal space not visible after deactivating user in LDAP

[Kathleen James]

We're using Crowd and LDAP to manage users and recently migrated from OnDemand to a server version.

We had a duplicate account with a personal space (different emails/different usernames). We deactivated the duplicate user, but expected to be able to see the old personal space. The space is still in the database but is not visible, or searchable. 

How can we retrieve those pages?

[Jonathan Simonoff]

In my experience, you should still be able to navigate to the space by specifying the URL –

http://confluence-base-url/display/~username

An administrator (may need to be a super-user, a member of the confluence-administrators group) should be able to move any pages out to a different space.

[Mike Rathwell]

Kathleen,

Jonathan's approach is certainly the right first step; so you don't end up with content stomping on each other, have your friendly neighborhood Confluence admin move the content you want preserved over to the "new" user personal space.

You may still end up with content now in there that the owner can't touch so you may find that you need to do one or both of a couple of things:

• Set permissions on the migrated content specifically so that the "new" owner has full rights over the "old" user content.
• Caution; this one isn't really sanctioned by Atlassian but I've done it and gotten away with it so YMMV:
  1. In the Confluence DB, look in the "user_mapping" table and find the "new" user (and "old" user if still there) to find the user_key
  2. In the content table, if you have the "old" user_key, search for all content the "old" user owned. If you don't have the "old" user_key you'll have to do this by title. This isn't as exact as common content names can and do exist across different spaces but if the "creator" and/or "lastmodifier" columns have a user key not found in the user_mapping you have a rather better confirmation you have the right content found
  3. Change the "old" user_key in the "creator" and "lastmodifier" columns for the content you found to the "new" user_key. The "new" user now owns and has the last history for all the content migrated to the new space. An added side benefit is that content created by the "old" user won't show something like "Created by <user> (unknown user)...." up in the header of the content as it all got migrated to the "new" user.

As I said, that second one is HUGELY a YMMV and probably should take a shot at it first on a dev system but I have had success with this in the past.