|
[
Permlink
| « Hide
]
Jason Shao added a comment - 28/Aug/05 11:31 PM
We have a similar situation where we'd like to distribute management of our groups to as low in the organization as possible, without giving out privledges to admin the entire install. An additional per-group privledge to "administer this group" allowing us to assign users who can add/delete group members for just 1 group would be perfect.
We also really need this. We have a growing number departments across the company beginning to use Confluence. Each department has different permissions they need setup via groups, but it's obviously too risky for me to give admin logins to a number of people for sole purpose of creating groups and assigning people to those groups.
As it stands when a department or team needs a group to control access to specific pages, they need to send me or one other admin the name of the group and the members to add to this group. We either need this feature or we need to move Group management moved out of the Admins domain so we can give certain people permissions to manage just groups and users. With the new usermanagement in place (Confluence 2.1), we will have another look at this issue.
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.
Hi Jens
you wrote on Dec 19: We tried out the version 2.1 this week and unfortunately there is no improvement to this issue. Regards 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 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
 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! 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 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.
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.
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.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Permission to invite others into group
