This is interesting to us as well. We use Confluence as a general, public content management system for our documentation, FAQ, and other goodies. We want new visitors to have to sign in. Before activating that account, however, we would like there to be a manual approval step. Perhaps if we had some control over what groups the self sign-on users were added to, we could sort this out ourselves. We shunt new users into a group that has no particularly useful permissions, or restricted ones. In order to enable full access, an admin would have to add that new user to other, more interesting groups.

Actually, it occurs to me that this might be enough to accomplish what we need. If we set view permissions to be other than 'confluence-users', then a manual step is necessary to allow new users to view these pages.

We too would like a way to approve new users. Even something as simple as a notification when someone creates a new account would be an improvement...

Additional to e-mail notification, I could also imagine a macro which lists all recently registered users that have not been assigned special rights yet. As my university is expecting multiple registrations after the piloting phase, this would make it a lot easier to keep track of new users.

Having approval for self-subscribed users is definitely a GOOD THING to have! Please bear in mind, that this should also work with the internal Confluence user database, if account management is delegated to LDAP, so that self-subscribed and approved users do not pollute the LDAP server, but members of the institution still have automagic access without self-signup.

I am in favor of this, but perhaps with a slightly different spin... What if there were three different types of spaces: public, private, and "quasi-public". Public would allow for anonymous access, as it does today. Private would allow for authenticated (and provisioned) user access, as it does today. "Quasi-Public" would appear in lists of available spaces but the user's request for access to the space needs to be approved and the user need be provisioned with access by an administrator-- and hopefully, eventually, a space administrator.

Saw this listed in the FAQ as related to being able to control the self-service account account creation so I'm going to comment here eventhough this seems a little different. We'd like to be able to customize account creation a lot. For example, users within our company would be able to automatically create an account and we'd need to validate via email or something like that. External users who we are granting access would need another validation mechanism like a key of some sort. The information in our wiki is proprietary but we will have partners collaborate with us so we will have them in the system but control access to what they can see. I expect we'd need to code this as it's so specific but wanted you to see the kind of need we have.

Regarding the previous comment, the new LDAP support in Confluence 2.1 allows delegation to LDAP without having to create accounts in Confluence.

This would be great for us. We have an internal wiki and we want employees to be able to sign up themselves, but we want to have a way to spot check and prevent people from creating "joke" or multiple accounts.

Related to this, our IT group wants to manage users from Active Directory, but that's not useful if we still have to create Conf accounts manually.