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; } } }

JIRA Newly installed - Best practices Question

satyanarayana v

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.

Accepted answers

Nic Brough -Adaptavist-

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)?

All comments

Nic Brough -Adaptavist-

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

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 v

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-

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 v

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)

Welcome!

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

Quick Links

Find more posts tagged with

confluence

jira

jira-service-desk

service