|
Hi Erik,
Yes, I myself exactly think in same way. Some of these user administration part should be delegated to space admins to make easier life for Confluence Administrators and also to expeditie such requests by different space owners. Let's hope, Atlassian folks are watching this issue! cheers, HI all,
We exactly think about the same things for space moderators and their rights (group management). It coulld be nice to get those functionalities in a near futur release version of Confluence Cheers, Would improved external group management help meet these requirements at all?
This is what we're working towards at the moment, with a new user management component (Polis/Atlassian-user) and better external group and user management. Perhaps if you can have all your Confluence groups stored in LDAP (Active Directory or whatever), it is then simpler to distribute administrative access to those groups in the directory. Hi Matt,
I'm not yet sure how new user management component works. But whole point here is to let Space Administrators decide how they want to play around with their space. Hence they should be able to manage user groups associated with that space. If given user is not present in system then they should be able to add to system. Agrred This last condition will be unnecessary once confluence groups are moved to LDAP directory. Also In my view, Space admins shouldn't able to remove user. They can only remove them from user groups associated with given space. B'cause it quite possible the given user might be associated with multiple user groups for different other spaces. Do you think my storing groups in LDAP, space administrator can do that ? - You're right, space admins should definitely have access some of the group management functionality. I was suggesting external user management as a more near-term solution, if you have a suitable LDAP server set up.
With LDAP group management, Confluence looks up members of a group in LDAP. So it becomes the problem of your directory service to manage these groups. LDAP servers typically have very fine-grained security controls, so you should be able to give your space administrators access to create and/or administer specific groups on your LDAP server. Even if they cannot do it directly, many large organisations have existing processes for creating and updating groups in the directory. Agreed, given the LDAP group management this can be possible.
To be frank, I have not yet explored that path yet ( how to manage user roles in ldap/active directory.) But I'm sure providing this feature in confluence itself shouldn't be much difficult! That's what I feel! cheers, Hi Rajendra,
We are encountering the same issues as you.. We have implemented external user management in Confluence and found that this is a good solution to the problem. The trouble with doing group management directly in Confluence is that you end up having group structures duplicated in each application you run.. We are going to be providing our users with a dedicated user/group management application (sitting on our LDAP server) that lets them create and manage there own groups. However, this application will run outside Confluence. Then all our applications (Confluence, Jira, and inhouse apps) can make use of the same set of groups. It would be trivial to add a link to this group management app in banner of Confluence. Damon. This feature is a necessity for my company to implement Confluence. We are a Fortune 50 company with 120,000+ employees and our LDAP is too big for groups to be added and leveraged without having to wait minutes for group membership verification to come back. That's something that's being worked on but, short term, we need the applications themselves to manage security groups and to just use LDAP for account authentication.
hi Peter,
We couldn't wait till Atlassian make this feature part of their release. I have developed one plugin (with help from Atlassian!) that allows space administrators to add/remove users from wiki space to which they are space Administrator. Plugin makes remote calls to Jira to add/remove users. If you are interested you can find more information about this plugin here : http://confluence.atlassian.com/display/JIRAEXT/User+Management+Delegation+to+Space+Administrators cheers, Rajendra,
That's awesome, thanks for the note! Unfortunately we're not using Jira so I think that kills your plugin for us. We're using LDAP for user authentication (well, trying, we actually use S/LDAP and that's not as straightforward to set up, apparently) but we can't use it for groups so we need the functionality to be inside Confluence itself. Peter Hi Peter,
Since right now we are using Jira for confluence user management; this plugin works pretty much tied to Jira. But if you have time, you can change the source code to work it for LDAP User management. Since we are not using LDAP user management in our current environment; I may not be able to do the changes for the same. Let me know if you need any help on that ( if you decide to give a try on it). Source code is already avaialble on the plugin website. If necessary will provide latest source code too. Still need to upload it on SVN. thanks, Thanks! Let me bounce this to someone who has time and expertise to look
at the code and see if it's doable by our resources. If not, Adaptavist is willing to assist as well, albeit for a consulting fee. Thanks for the follow up! Cheers, Peter Yes, yes, yes... In a very decentralized organization (such as ours), this would better enable enterprise-wide use of Confluence. I'm all in favor of implementing this feature!
Hi Peter / Geoffrey,
I have worked on upgrading the delegate module so that it can allow users to manage users (which are managed within Confluence). thanks, Hey Guys,
I have developed a plug-in which satisfy some of the above requirement like deleagation of user groups management to Space Administrator. Details of this plugin are available at http://confluence.atlassian.com/display/CONFEXT/Custom+Space+User+Management+Plugin your feedback is very much welcome. thanks, Rajendra,
That's great! I'll jump over and take a look. Thanks! Peter All,
As an extension of this issue we want our users who are space admins to export certain data from their spaces and import data back. However the import data is available only for Wiki Admins and not space admins. We want to import that into an existing space under a different page. Let me explain with an example. We have a wiki space call "Ideas". Under that we have a page called "Idea 1" and we have many sub pages under this Now we wanty to export a couple of pages from Idea 1 and import back into the same space as "Idea 2". Today there is no import functionality designated to the space admin Thanks Laks Just copy the pages - go to the page info tab in recent version of Confluence and you'll see the copy option. You can change the page title/parent when copying a page.
Current workarounds for this issue:
none of these workarounds will work for us. Mainly because:
We don't use Confluence LDAP integration (which IMO doesn't scale well for large deployments, especially if tight coupling between LDAP and wiki is not desirable). Granting admin rights to space admins would give them more power than what is desirable. Granting site admin rights to a specific user doesn't scale well for large deployments. All we would like, is to make it easy for space admins to give content creators appropriate privileges. Instead of assigning privileges to individual users, we would prefer to enable space admins to create a group, specify the permissions for the group and then assign users to this group. Maybe the simplest solution would be to create a new group every time a space is created. The name of this group would match the space key. And a simple UI for adding/removing users to/from this group would be added to the space permissions view or into a new tab in the space admin view. I'm moving towards a Maximum Authority
 scheme were 80% of spaces are 'open' to confluence-users, the remainder would be closed, and regulated to space specific-groups. I still do not want to manage the groups for the remainder 20% I want to delegate management of groups which are going to be specific to the spaces anyway, to nominated space admins. This seems such a neat way of delegating, another checkbox on permissions checkable by system admins of 'space admin management' would be spot on.
The custom space management plugin Current options:
1. Install the Custom Space User Management Plugin to allow space administrators to manage users at http://confluence.atlassian.com/display/CONFEXT/Custom+Space+User+Management+Plugin 2. Install the Invite Plugin to allow space administrators to invite users by email from http://confluence.atlassian.com/display/CONFEXT/Invite+Plugin 3. Use external user management such as LDAP or Active Directory and allow space administrator to grant users through there 4. Grant site administration rights 5. Grant site admin rights to a specific user and ask space admins to delegate their user administration tasks to this person Hi David,
It's good to know that Custom Space User Management (CSUM) plugin is recognized by Atlassian as a valuable tool for their users. We are trying to address all needs from users. If you have any feedback please do add ticket at http://developer.atlassian.com/jira/browse/SUSR cheers, |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
User management delegation to Space Admins
In particular:
1. The ability to assign a sub-set of groups to a space.
2. Allow space-admins to add new users and assign users to the restricted set of groups.
3. Allow space-admins to manage user membership within those groups.
Use Cases:
1. We sign a new customer and setup a new space. An account lead is assigned to manage the space. The account lead then needs to add the customer's users as well as users from our internal staff (developers, support staff, etc...), contractors, etc... to the space.
2. Users at an existing customer change. The account lead needs to remove the old users and add the new users.
3. Internal support staff change and/or are re-assigned. Account leads needs to add new internal users from the support group and/or contractors to the space.