Personal space not visible after deactivating user in LDAP

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?

2 answers

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.

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.

 

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published Thursday in Confluence

Color tables for a shiny Confluence page

...; ## Developed by: Alana Fernando ## Shared with love ## @param style:title=style type|type=enum|required=true|desc=Choose a style.|enumValues=Style1,Style2,Style3,Style4,Style5 ## @param alignment:title...

141 views 8 10
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you