Does this also apply to personal spaces?
Due to Confluences lacking LDAP-support for Lotus Domino we are not able to auto-populate the confluence-users group.
Which in turn means that right now new created personal spaces don't give read-access to anyone but the author which confuses pretty much everyone.

With this feature I hope that we can configure default-permissions also upon creation of personal spaces?

FYI: I attended this year's Atlassian Unite in Frankfurt, Germany, and went to the Birds of a Feather session with Matt Hodges, the Confluence product marketing manager. We were around ten people, most of which were concerned with enterprise features like this one (with regard to this issue in particular, I made the experience you can't even use the API to track and enforce space permissions via a batch job, since the API is not granular enough). In any event, Matt explained that they are trying to identify themes in which they can group features, like they have done for usability with Confluence 4.x, in order to focus development (but to the detriment of other features). In any event, Enterprise readiness can be seen as one of those themes, and they are aware of the fact that there is a lot to improve in this area. I don't know when it will be there but my impression is that Atlassian is listening. My 2 cents.

What is up with that Atlassian? (In reference to Royce Wong's comment)
Is Atlassian working to alienate those users who are not moving to their cloud-based service?

This affects ALL our users, as not many of them have created personal spaces before we upgraded. 400+. Just saying, it does affect a lot of users.

+1
I hate all those popular requests, open since many years and still untouched by atlassian. This is one of them, causing pain in enterprise setups!

Hmmm... setting default permissions is not available in "regular" Confluence but available in JIRA Studio?
http://confluence.atlassian.com/display/JIRASTUDIO/Configuring+Default+Space+Permissions

Exactly as Nils Hofmeister described. We now have external users as well, and this has become a huge security problem for us, as it's too easy for someone setting up a space to 'reveal' that space to all other users without realising what they've done.

Please prioritise this issue.

Same issue for me as Arian described it: we got internal and external users. As a default internals may view everything while externals shall be restrictedx to certain spaces explicitly.

This means if I could configure that group X shall get default rights instead of confluence-users, this would eliminate all the pain I will definitely have in the next months explaining users how to configure space permissions and fixing errors. This is also a severe security issue - we need to rely on people doing things right instead of solving this problem programatically. Awkward.

Similar approach here Mark, but we wrote a simple Java based client that uses confluence's API to create the space, as well as some default pages and gadgets.

We have this java app as the final stage in an approval work flow so users can request new spaces without actually creating them.

The only acceptable solution I've found so far is using the Confluence CLI and then script the space creation, includding adding permissions:

./confluence.sh --action addPermissions  --space "spaceKey"     --permissions "editspace"  --group "My Group Name"

Not sure if anyone has tried this approach, but any feedback will be welcome

xab

This is really annoying - fix it please!

+1,

due to the new improved LDAP integration this has become more important. None of my users are in the confluence-users group and I cannot expect all my users to set there privileges when creating personal (and even global) spaces.

Added status to the issue

We also need more granular control of the default permissions that are being set in createpersonalspace.vm aside from just 4 options of if registeredCanView/Edit and anonymousCanView/Edit. We have hardcoded the checkboxes as Hidden Form Tags in createpersonalspace.vm as 1) permissionSetter.registeredCanView = true, 2) permissionSetter.anonymousCanView = true 3) permissionSetter.registeredCanEdit = true, 4) permissionSetter.anonymousCanEdit = false. But the problem is that we would like Personal Spaces that are created to allow only viewing by Anonymous users and NOT the ability to allow Anonymous Comments. The current implementation does not allow us to have spaces have Anonymous view access but not Anonymous comment adding privelege. The problem is that when permissionSetter.anonymousCanView = true - it sets the security permissions for both "Anonymous can View" and "Anonymous can Add Comments" together. There need to be more fine-grained permission options that can be set as the defaults in createpersonalspace.vm.

If Confluence is an enterprise wiki solution, this feature in allowing site administrators to preset the permissions and membership list of any existing wiki spaces as well as new wiki spaces is a must. there are always some groups / members (e.g. for support or content monitoring purpose) that will always need certain access to all spaces. when can we have a feature like this? Thanks.

This feature is huge for those of us with large confluence installations. Setting default permissions for spaces is time-consuming and with personal spaces impossible. Huge +1

Thanks for your comments; we agree this feature is useful when creating spaces and wanting to set default permissions. We will consider this feature for a future release.

If you want to understand how we select features for future releases, please read:
http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements

This also needs to allow variables in the defaults.
Like %space%

so i can add %space%.developer, and when the space gets created it places the space key in that var.

This would help with our LDAP setup, because we map roles to ldap groups mapped by space key.

Adding another vote to the chorus. The default space permissions are just wrong for us, and so we have to remember to edit the space permissions every time we create a new space.

In particular, we would like permission for removal of pages, news, and attachments to be OFF by default.

Also, it is odd that Export Space is ON by default, while Export Pages is OFF.

This issue is a real headache for us too, as we want to run a hybrid intra/extranet on a single Confluence instance so that our staff have one place to do stuff, whether it's with external parties or internal-only. The default permissions for new spaces are too open for this – I appreciate that they were intended to encourage knowledge-sharing – and we need to be able to control these. Running a frequent cron job to revoke "all authenticated users" permissions on all spaces seems way too clunky. Alternatively, we have to limit space creation/admin rights to a small group of trusted and trained individuals, but that puts a hurdle in front of users that could limit uptake and use. Wish I had more votes...

I need this function!!

Is vital to better organize users group with external management.

And you should restrict deleting "confluence-user" group is this functionality is not implement. All new projects add a group that not exist!

Since we've got multiple Atlassian products implemented, we found it cumbersome to deal with all the product-specific groups (jira-users, confluence-users, etc). Instead, we've adopted a more generic "atlassian-users" group in Crowd that grants access to all of the tools.

Unfortunately, Confluence seems to be hard-coded to use "confluence-users" (a group that we no longer use and in fact doesn't even exist in our Crowd directories). If only we could change the default permissions that are imposed on new spaces! As it stands, newly created spaces (including personal spaces) must all be modified to remove the non-existent "confluence-users" group and to add the "atlassian-users" group instead.

Though it's shown quite prominently on the space creation page, it would be nice if the "allow access to confluence-users" tickybox was off by default. Revoking access is slightly tricky business.

My need is to be able to set a policy for anonymous access. To only permit anonymous access to nominated spaces (global/personal) as a system admin. Anonymous access setting/unsetting should be optionally settable.

Driver for this is personal spaces get created automatically with anonymous browse. People store corporate data there, I want it protected by default. Currently I have to resort to SOAP / cron

Interesting trick, but not related to this ticket at all...

Without this feature, the easiest way to maintain a private wiki on the internet is as follows (to the best of my knowledge):

setup:
o Allow users to sign up for themselves.
o Globally set confluence-users to have no access.

per user:
o have user sign up. By default they are a member of the confluence-users group and can't see anything.
o Administrator manually removes that user from confluence-users group, and adds them to verified-users group.

+1

(and where's that cool google-like group-selector feature, too <grin> )