JIRA Newly installed - Best practices Question

satyanarayana visampalli April 29, 2014

1. In general, what circumstances make me to choose group instead of role and vice versa?

2. In general, what circumstances make me to choose one permission scheme for one project (one to one)? By doing this what is the advantage or disadvantage?

3. jira-users, jira-developers, jira-administrators -- these are jira default groups to most inner working parts -- by using these existing groups is JIRA easily manageable or we loose flexibility if we use these if projects increase year after year.

4. I saw many online help but everything says how to use jira but not how to build jira? Can some one suggest me how to build jira (thiking of easy maintenance as we move forward)

Thank you in advance.

1 answer

1 accepted

3 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 29, 2014

1. Keep group usage to a minumum, and ideally, don't use them in permissions or notifications at all. If you use roles exclusively in the schemes, then you have the full flxibility to use groups on a per-project basis. Best of all, roles can be maintained by the project owners, not relying on the admins.

2. Advantage is that you can do different things in different projects, and reconfigure them quickly without worrying that your changes might break other projects. The disadvantages are users moving between project needing you to explain the differences every time, admins having to maintain swathes of slightly different schemes and inconsistency across the business.

3. Use those groups where you can, but don't be afraid to add others when you have a decent reason to do so.

In points 2 and 3, the simple answer is analysis and moderation - don't create millions of things, it's inconsistent, confusing and hard to maintain. But don't be afraid to add justifiable ones. A good middle-ground is to define sets of usage and share beteen similar projects - e.g. "development type project", "operations type projects", "team type projects".

Roles are seriously a lot more useful that groups in the long run and make sharing and maintenance a LOT easier

And 4 - I don't know waht you mean by "build"? From source? The .WAR version? Standalone installations (which don't need any "build" process)?

satyanarayana visampalli April 29, 2014

Thank you Nic. I really appreciate your answers. Please suggest best practise in this case.

Project A -> Manager Team (3 persons) --> Dev Team (5 persons) --> QA Team (3 persons) --> Release Team (2 persons)

Each Team is conditionally dependent on Other for approvals.

Like you said to use the groups to minimum and use roles better, Here If I create 4 roles and 1 group vs. 4 roles and 4 groups (considering flexibility) What can be ideal considering flexibility

I appreciate it.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 29, 2014

You've pretty much got it there - add four roles, then for each project, your project administrators can add

A group would come in handy if one or several of these roles are always going to be the same people. If it's always going to be the same people in every project, then I'd still use roles because the use of roles gives you the flexibility - you can put the groups into the roles anyway.

satyanarayana visampalli April 29, 2014

Thank you ver much Nic. As I learn best practices, I hope your advice will be helpful for other people who are working with JIRA from scratch.

Project A -> Manager Team (3 persons) --> Dev Team (5 persons) --> QA Team (3 persons) --> Release Team (2 persons)

4 roles(1R,2R,3R,4R) and 1 group(1G)

Jira-users versus Newly created group

What is best practice to use as I am going through your forum replies I found this.

The most common culprit is "Jira users". Atlassian have a really bad default model where they use "jira users" to mean "can log in" (which is fine in itself), but then use it for "can use project" as well. This then gets copied ad-infinitum, until an admin runs into a case like yours, by which time, "jira users" is used all over the place, and just creating a new user automatically spams them into multiple projects. It's a pain in the neck, and I think every client I've ever had has suffered from it (apart from the people who are migrating to a clean Jira - with a clean system, you can set up a useful default before any damage is done)


Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 30, 2014

Yes, that's referring to the default setup problem.

Jira users is a default group. It is used to say "these users can log in". That's fine on it's own. But the group used to be used in permission schemes as well to give a default "these users can see and use the project" and what used to happen was people would copy permissions to use in their new projects. So the usage would expand and expand and expand.

Then, one day, people would realise that they have a need to let a new person only see one or two projects. The immediate effect of the defaults is that if you add the new person to "jira users", great, they can log in. And see every damn project in the system because the jira users group is everywhere. To limit them to a project, you have to undo all those defaults.

The settings have improved. The permissions do NOT use the group any more. They use roles instead. But they STILL put jira-users into the role of "users", which has the same effect. So now, to unpick the "anyone can get into every project", you still have to go through ALL the projects, removing jira-users from the role of users, and adding back in the people who should still be there.

Every Jira I've ever been responsible for has had this problem, and I've always ploughed through my standard fix - either remove jira-users from everywhere except "can log in", or remove it from "can log in" and use a separate group from that.

Suggest an answer

Log in or Sign up to answer