We are using JIRA in just IT now, but the business-side is very interested in starting to use it - Their one caveat is that they want control over who can be given access to what projects, instead of having to request an IT admin to do it. We need this functionality! I've voted.

This should be fixed by allowing group owners (or "Group Managers" as above). Look at the permission model for AFS if you want to see how this is done - any user in the system should be allowed to be able to create groups, and they should own the groups they create. They should have add/remove/delete permissions for the group, and perhaps the ability to make others group managers. Right now I have to make groups for the various people hosting spaces on our site. I would also have to add users one by one if I hadn't written an xmlrpc script to do it. Most space admins on my site have a list of users they want to set permissions for, and they just send me a list of logins. I have to run the script to actually make these groups, and I changes have to go through me. This could all be fixed by making group management something anyone can do.

I agree with some of the earlier comments on this issue. Confluence falls short for very decentralized organizations, where it would be desirable to delegate/distribute some level of administration. Space administration is a good step in this direction, however space administration needs some user/group management capabilities added to it.

As pointed out by Peter I also think that CONF-1514 and CONF-5302 are related to another. They both are about building up groups by non-admins. While CONF-5302 suggests to leave this to the Space Admins CONF-1514 is about a new permission which is "add users to group".

Our current workflow is more like having "Group Managers" i. e. each group has one or two persons responsible for it. They bundle requests to the admins to add users to groups (or to remove them). This especially solves the problem that administrators might not know if they are allowed to add user U to group G just because user U asked them to do so.

So my preference is more to CONF-1514 that is give permissions somehow but in that way that for each group it can be stated who will manage it (I think at least two people are useful, a "lead" and a "deputy"). Btw: A comment-entry for groups would be useful to, just to document for what purpose they got created... but that's another story.

I think that the request at http://jira.atlassian.com/browse/CONF-5302 mirrors this request and I am concerned that having multiple requests for basically the same thing is working against us!

This would be a big help in our installation as well. We do not give Global Admin permission to many people, so allowing group additions would help a lot of people out (as well as taking a load off the admin

Hi Stefan,

I think Jens meant after the new user management system had been implemented in 2.1, we would look at it (in a future release).

Jeremy

Hi Jens

you wrote on Dec 19:
> With the new usermanagement in place (Confluence 2.1), we will have another look at this issue.

We tried out the version 2.1 this week and unfortunately there is no improvement to this issue.
Do you know some more about?

Regards
Stefan

We have the same proposal: delegated administration for groups. Something like a group owner or group admin. In our company we have about 30 Departments and Business Units with seperate Spaces and Permissions (groups). Its boring for the IT department to support each change concerning the groups. On the other side it is boring for the Space Admins to handle 80 users as Individual Users.

With the new usermanagement in place (Confluence 2.1), we will have another look at this issue.