Ben:

My apologies: I was still revising that last comment when I got your reply. I've added a good bit that should make my own perspective plainer.

On reflection, I think I have to agree in most cases, though the relationship between space-admins and the wiki admins bears on how much access a given space-admin may be willing to grant to confluence-users. If the entire wiki is like our corporate headquarters, then a space is like my cubicle that doesn't even have a door - anyone who can get in the front door is generally authorized to enter it, and only confidential items and personal valuables are kept under tighter control. if it's more like an apartment building, with any tenant able to buzz any visitor in the front door, it's a little different - not only do I have a door on my space, but I keep it closed and locked most of the time.

Finally, of course, it's about responsibility. As a space-admin, I would not want to be the one who let someone in whose trustworthiness did not measure up to the general level expected of registered users; as a wiki admin responsible for all of the space owners in my wiki I would want to reserve the right to rule on all admissions. In my case above, however, and possibly in yours, it would be perfectly acceptable to allow space-admins to enable users who didn't exist yet, and let the wiki-admins control who got into the whole wiki.

If you still feel that you need this feature, it might make more sense to create another one, since this one is closed, having satisfied the original requestor, who will not want to reopen it and can't give it to someone else.

Brian - Your right - creating a new user does put them in conflunce-users by default and they MUST be in that group to see anything. BUT - the confluence admin (in my experience) is never going to deny a user access to confluence if a space admin requests to add them. It makes no sense to make confluence-user more secure than a space's securing group. If your running multiple spaces on your wiki, then you have to think about how to grant access to them - and secure spaces must be secured with something more than confluence-user.

What I'm trying to say is this: I can not imagine a use case where a confluence admin would say "sorry. but that guy, can not be a confluence user even though you have permission and authority to add them to your space".

To me the best option would be a configuration that gives some users (let's call them space admins) the ability to create new users. At the time when you create a space-admin, you also assign them groups to "own". They can then add or remove users from these groups.

Ben:

I agree, with one major reservation:

Creating a user normally grants membership in the default group, confluence-users. This will (or should...!) fail when not executed by a global wiki administrator due to lack of permission. I don't know whether Confluence has any structural dependence on default group membership, such that a registered user who is not in the group is an anomaly that experiences strange behavior, but I have some doubt that they have avoided that altogether.

My doubt is based on some early experiments with automatically adding users from within an authentication servlet filter – before I realized that the API method userAccessor.addUser() did not add the newly-created user to the default group without my explicitly requesting it, I found that some things did not work as expected for that user.

This may be unfair to the Atlassians; since that was some time ago, and I was very new to Confluence at the time, this impression may well be unfounded, but, well, caveat emptor.

I'd like to head off the obvious quick-fix in the event that my misgivings are correct: Due to its global nature, and the fact that other space admins depend on the user's admission to the wiki having been approved by an admin responsible for the whole wiki, let me point out that it would not be appropriate to grant a space-admin authority to add users to the default group.

Another problem that I faced as a wiki-wide administrator (which, I suspect, may be your real problem) was that of space-admins who wanted to bring their entire (large) workgroups into the wiki, and couldn't add users to their groups who hadn't been registered yet. They were faced with the daunting task of adding users to the groups one at a time as they got registered.

Since I had the luxury of knowing that no user could log in to an account I created without satisfying the global SSO system, I had no problems using the Confluence Java SOAP client to add users for space-admins I knew who submitted their requests in bulk files.

The Custom Space User Management plugin does not allow you to create users. In an environment where users are coming from the wild (versus already in LDAP) and joining project spaces, the project manager (space manager) should be able to not only add users to the group, but create them if they don't exist. I think this is higher than trivial.

A minor part of this suggestion is very slightly addressed by CONF-9129, which splits the existing confluence administrator permission in two, meaning that complete administrative rights are not required to create users and groups.

As per previous comment, I've reduced the priority to trivial due to my practical need having been met by the Custom Space User Management plugin, despite its not fully meeting my exact specifications.

While it does not fully meet the exact specifications of this request – which may yet be desirable from a theoretical standpoint – we find that in practice, the group creation and management functions provided by the Custom Space User Management plugin can be used effectively to meet all of our administrative needs. Most importantly, it removes the burden of non-global group creation and administration from the wiki administrators, which is the problem for which this Feature Request was initiated.

Accordingly, so far as this reporter is concerned, this issue may be closed. However, if the advantages of the exact specifications I have listed are considered worthy, it may be a good idea for it to remain open but at a greatly-reduced priority at your discretion