nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

Nic Brough -Adaptavist-

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...

All comments

Nic Brough -Adaptavist-

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.

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 (

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.

Radu Dumitriu

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

Give it a try.

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?

Sorin Sbarnea (

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

crowd