Defining group membership for users is lots of work. Anyway to make it simpler?

[Daisuke Niwa]

Hello there,

I am asking this question on behalf of one of my customers.

They are using JIRA, Confluence integrated with Crowd. They have apporoximately 2,000 users and each user belongs to his/her department.

Their Crowd uses "delegated authentication" i.e. username and password comes from LDAP, but group memberships are defined in Crowd.

Now, there are lots of groups within Crowd, and it takes some effort to assign all the necessary group membership to a user each time they add a user.

I asked them to consider reducing the number of groups, but they said it is not possible because their Confluence spaces need access control in accordance with each groups, and the number of their Confluence spaces are rather large, requiring different set of access control.

Is there any way they can simplify their process?

Any ideas greatly appreciated.

[Nic Brough -Adaptavist- · Accepted solution]

Pretty much what you've already said - cut down the groups. If they don't want to do that, then they need to accept that they're going to have a lot of work maintaining them.

I think it's worth asking them how they think they'd like to "simplify" it - could they use a small number of generic groups and maintain individual space users? Is the Crowd interface the issue? Are they doing the same thing every time and you should look into scripting/templating?

Find out what they think would be more simple, and work from there. It's hard to deal with "it's too complex" when you don't know wha they think the complexity is...

[Sorin Sbarnea (Citrix)]

I think that one major problem with groups is the inability to rename them and to assign descriptions and an owner to them. Adding this would enable people to manage them.

[Nic Brough -Adaptavist-]

Yup, completely agree, although I've looked at the possibility of renaming groups in the code, and it's a lot nastier than it sounds to implement. I can understand the resounding silence from Atlassian on that - it's not a minor tweak. Descriptions would be quite easy though.

[Daisuke Niwa]

Hello All,

Thank you for your respective answers.

Let's think about Confluence. Suppose your organization have 50 departments, and each department has 30 staff.

You create a Confluence space which can be accessed by only your department and one different department. Let's assume all departments have similar requirement.

In this scneario, you would probably have to create 50 different groups, and assign them to 1,500 different users in Crowd.

Isn't this a lot of work? Anything can be done about it?

[Nic Brough -Adaptavist-]

I can't see any way around it. If you want to use a separate group for each department, then you've got to maintain it somehow.

I'd be asking the question "do we really need this level of segregation in our applications". If the answer is yes, then there is no way to do this more easily - you've got a mass of data, you need to maintain it. There's no way to simplify it because your users have decided they need the complex mass of data.

Personally, I push this on to the space/project owners. In Jira, use roles, then the project admins can add individuals. In Confluence, the project admins can add individuals. If they think this becomes too painful for them, then explain the scale of the problem with group maintenance and get it recognised as a business problem.

From one experience with a Jira/Confluence install - 20,000 users, two main business units (split was roughly 8k/12k). Within each unit, there are hundreds of groups.

I maintained all the groups for the larger unit - in the sense that I'd set up a handful (6ish) of groups that really did need to be groups, and all the projects used roles for most of the access. Project owners were responsible for users in their areas.

The other group hired two full time group administrators doing *nothing* else because they didn't want to delegate the group maintenance to the project owners.

Short answer - talk to your users and get them to think about group maintenance properly, as a business problem.

[Sorin Sbarnea (Citrix)]

Get groups from LDAP mailing lists, but filter them and use a special mailinglist that has to include the other mailing list that are supposed to appear in Jira/Crowd/Confluence.

People in need of groups should ask IT for a new mailing list, which has to be added as a member of your mailing list.

Doing this you, the Jira admin, will externalize the group managment to the IT.

[Radu Dumitriu]

A way to make it simpler: https://marketplace.atlassian.com/plugins/com.keplerrominfo.jira.plugins.rightsdna

Give it a try.