How do I remove the permissions for the owner/creator or a personal space in Confluence?
Asked by Andy Boze:

I have a number of personal spaces that are not being used. I don't want to delete the spaces yet, but I don't want the users who created them (or anyone else) to be able to view or administer them. I set the Group permissions to allow confluence-administrators to have full control. Then I deselect all permissions for the user who created the space. When I click the "Save All" button, the user remains with full permissions to the space. Is there any way to remove a user's permissions to the space he created?


Answers:
author: Nic Brough -Adaptavist-
body: I'm afraid you can't pull the owners permissions to their space. A user's personal space belongs exclusively to them, so it doesn't make a lot of sense to remove their rights.

One immediate problem - if you did it, they suddenly couldn't see it and clicked "create my personal space" again.

comments: author: Filipe Dias
body: Hello.

For me that makes no sense.

As the administrators of the instance we should be given the tools to manage all the content and accesses of the Instance, whether it's a JIRA project or a Confluence Personal or not space. We might decide that personal spaces are not to be shared with any other members of the team, so, we might want to remove only the admin permissions to the owners.

If a user has a personal space and has admin permissions to it he can do lot's of things he doesn't even know is doing, like for ex using the personal space to share work content with another team, and them he leaves the company and the space lies there as a zombie space and not managed centrally. And deleting ir might make us loose important information and we don't know about it.

So, being able to remove "Admin" permissions to the personal space owner is a must.

Thanks.


author: Nic Brough -Adaptavist-
body: I do see your thinking there, but there's an important element that I think you're missing here.

There is a word that is vastly under-emphasised here. When we say "a **personal** space", Confluence really does mean personal. It absolutely belongs to that individual.

Your organisation certainly owns the service the space is within, and your admins do have admin rights over personal spaces. But the personal spaces are f**or that person**, not the rest of the organisation.

"Being able to remove admin permissions from a personal space owner is a must" is absolutely wrong. It's the wrong way of thinking about it, not for any of the reasons you give being wrong, but because you're not realising that the space belongs to them. By definition, it's theirs, and hence they absolutely always should have admin rights over it. Because it's theirs.

The right way to think about it is that **it's their space**. If people are doing "bad" things, then you need to think about how to deal with the problems they cause (and don't get me wrong, get 2 or more confluence users in a system and I will guarantee that at least half of us will abuse our personal spaces in some way, mostly unintentionally, but it's going to happen)

So, when you feel there's a need to take away admin from the owner of a space, that's the point at which the space is not really a personal space any more.

Don't take their space away from them. Move everything they're misusing to the right shared space, and let them carry on with their own space.

There's a simple rule to give to all your Confluence users that can help with the way they (and you) are seeing personal spaces:

**Assume anything in a personal space is wrong**

In Adaptavist's Confluence, that's a hard rule, with a minor exception - your personal home page is assumed to be a valid "profile of this human". Anything else is wrong, until it's moved into a proper shared space. And we have HR/data rules - if someone moves or leaves, they're asked to review their personal space and move anything before they go. Then their colleagues review it after they go, but before it gets deleted.


author: Filipe Dias
body: Hello Nick.

Thank you for your answer.

Yes, I totally understand the concept of "Personal" space, and I know if the users have the possibility to create one, then it's theirs to use as they well please.

The question is, if you have more than 700 users and a great deal of them don't even know what they are doing in terms of respecting company information policies and documents sharing, etc, etc, it becomes very hard to manage all this situations. The rotation rate of workers is very big here, so, we can't keep track of all the spaces and it's information before hand. The process is "automatic", if a worker leaves the company their stuff is deleted.

Yes the spaces are theirs bot at the end of the day they belong to the company, and I can't start talking to 300 users one by one explaining them they can't use the personal space to share corporate information within teams. They just won't do it and they will keep on doing things the easiest way they can/know (believe me, I've tried).

Unfortunately it's very hard to "educate" such a big and heterogeneous universe of users and I see myself forced to have some strict restrictions. I still give them the possibility to have a space where they can publish what ever they want, but now, this ones are created by me and restricted only to each user. They can't share it with anyone. This is very important to us. This is all I need.

Thank you very much for you time.

Filipe


author: Nic Brough -Adaptavist-
body: The problems you are having are not solved by taking away admin rights on personal spaces. You need better curation, and your users to understand (and implement) rules on not using personal spaces in bad ways.

If you really can't stop them doing it wrong and don't want to make time for proper curation, then there is a simple solution - disable personal spaces. (I'd create a single "scratchpad" space for people to play in, with the top level page locked edit and carrying a large warning that all pages over X days old will be deleted and it's not for real data).


author: Filipe Dias
body: Yes, I already did that.

Disabled the possibility for them to create personal spaces, now they have to ask me to have a "personal" space, and I create them without the "admin" permission, so they cannot share it.

My problem is with the 300 plus personal spaces that are already created and are sharing information, and of which I don't know how many of them belong to people that already left the company (have to check one by one) and also don't know how many I can't even see because they removed the administrator group from the space access.

Well, I'll get there ;) thank you very much once more.


author: Nic Brough -Adaptavist-
body: Ok, so you've change the process to prevent the problem, that's great, but I completely understand that your existing data remains an issue.

First thing I would do is connect up leavers to your user directory (manually), go to HR and ask them who of your 300+ have left. Unless they've already been deactivated or deleted in Confluence. They're the easier ones because you don't need to ask them anything, you can do what you want.

The harder ones are the existing users who have personal spaces. You're going to need to contact all of them and tell them their spaces are going (maybe allow exemptions for people who are good if it's a hard fight)

In both cases, I've had a Scriptrunner to hand, so I've been able to quickly identify deactivated and deleted users, and feed it a list of others I want to kill because HR tell me so, or that I've got their space on the list of ones to get rid of.

SR can then move their personal content to a shared scrap space (Structure was like "home page -\> page for each user name -\> personal content moved beneath each username wholsale). We ended up with a large, messy space, but relatively easy to curate because it's all in one place, and if people had linked to pages in personal spaces, they still worked because Confluence could redirect.

Or you do it the brutal way - just tell them all personal content is going and work through deleting it all a reasonable time after the warning.

It's a bit of a slog going through the housekeeping, but if it prevents continuing problems in the future, it's worth it.


author: Filipe Dias
body: I'll go with the "more or less brutal way" :) I'll create a new space for each of the still active users, won't give them admin permission on this new space and then send out a warning telling them they have X time to move things to the new space because the old one is going to be deleted.

I'm still stuck with two problems anyway:

1st is, there are for sure some spaces that I don't see because the owners have removed the Administrators group from them and if the user leaves the company I'll have zombie spaces. I might also have these already for users that already left the company.

2nd is, after sending out the communication I might have some users that are going to remove the Administrators group from the spaces access (because they don't want to have the trouble to move things and don't want to have their spaces deleted) and I'll end up with problem 1.

So, I know it's a war I won't be able to win totally, at least I won't have new cases anymore.


author: Nic Brough -Adaptavist-
body: Neither of those are actually problems! Someone with the Confluence Admin right can always see all spaces headers.

Not necessarily see the spaces content or existance when they're wandering around Confluence content, but the headers (where the admin happens) is always accessible to admins.

Imagine Dave is an ordinary user, as is Alice, and Alice has a personal space. Alice changes the permissions on her space to say "only Alice can see this space". Fine, Dave won't see it as he goes through space directory, searching or even gets given urls to pages within it. Dave sees nothing of it.

Now you give Dave admin rights. Dave, doing his day to day job, still sees no sign of this space.

But if Dave hits the admin cog to go into admin sections he now has access to, he will. One of the pages he now has is the list of spaces. \~Alice will appear in that list and if Dave clicks on it, he'll be taken to the space admin for it, where he could add himself (and others) to it, and even delete the space...


author: Filipe Dias
body: Oh, ok, I didn't know about that. I thought I would loose sight of this spaces.

That's great them. No zombie spaces left :)

Thank you very much for this hint. So, my plan is drawn.

Thank you once more.


author: Filipe Dias
body: I'm sorry, I have one question.

For what I understood, you are saying we have a list of all spaces on our Confluence Admin page, right?

So, here: "<https://XXXXXX.atlassian.net/wiki/admin/viewgeneralconfig.action>" right?

But I can't see any option to show me the list of all spaces. The only place I can see a Space list is here: <https://XXXXX.atlassian.net/wiki/spaces>.

Am I seeing this wrong?

Thanks.


author: Filipe Dias
body: I Guess I have access to all the pages (even the ones I don't see the content as you say) on [https://XXXXX.atlassian.net/wiki/spaces](https://xxxxx.atlassian.net/wiki/spaces) regardless, so, I think it's ok.


author: Filipe Dias
body: OK, found the page to manage all the spaces: <https://xxxxxxx.atlassian.net/wiki/admin/permissions/viewdefaultspacepermissions.action>

Thank you once more.


Tags: permission

personal-space