Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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.

3 answers

1 accepted

1 vote
Answer accepted

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

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.

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.

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?

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.

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.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Marketplace Apps & Integrations

☕️ Monday coffee with Jexo: Weekly Atlassian news roundup | 21st June 2021

Hi community 👋, as every Monday we're bringing you a quick update on what happened in the Atlassian ecosystem last week. There were a few interesting events like for example the announcement of th...

66 views 0 6
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you