JIRA system admin - start from zero

[CarmenS]

Hi,

I am a newbie in JIRA; we have an instance which hosts one dedicated project, and all the roles, permission scheme, groups, were created specifically for this project.
Due to many other team's interest to use JIRA within our organization, we want to start a new instance which will host all other projects.
We try to start right from the beginning, and not mess with too many admin roles, too much headache for JIRA system admin, and so on.

We use Active Directory for authentification, and i am confused on how to separate admin/dev/user roles.
1. is it better to have AD groups for ADMIN, DEV, USER, and separate the roles directly in AD?
This may lead to too much interference with Active Directory, too may groups inherited(TEAM1_ADMIN, TEAM2_ADMIN, TEAM1_DEV, TEAM2_DEV, etc)
2. is it better to have in AD groups as per our organisational structure(GRP_DIVISION1, GRP_DIVISION2...) and use also JIRA internal groups for separating admin/dev/user roles?
(do I need to create other internal groups also, or only working with permission schemes will be enough?)

3. How can JIRA space be divided for two or more divisions? The only separation I see is using projects, which can share the same workflow, custom fields, etc.
Can/Should any project have one, more or NONE JIRA Admins?
A JIRA Admin can for example edit a workflow, which may be associated to many projects. (His change will be intended for one project, but he will interfere with other projects workflow, which is not desired.)

How would an experienced JIRA system admin start this up?
Any help is appreciated.

Kind Regards,
Carmen

[Dave Theodore [Coyote Creek Consulting]]

In regards to questions 1 & 2, my advice is to keep things simple. Don't restrict things any more than necessary. When I set up a fresh Jira install for a client, I typically try to make use of existing AD/LDAP groups as much as possible. If there is an existing "all employees" or "all engineering" group in AD, maybe use that to grant the "Users" global permission, which will allow all members of that group to log in to Jira. You probably have a very small number of admin users, so it might be better to use the internal "jira-administators" group to grant "Administrator" and "System Administrator" permissions. If you use Jira's Roles to grant access to the projects, you can make someone the Project Administrator for a particular project and they can manually add the people to the project in order to give them the permissions they need. If you already have people grouped in AD, I usually try to make use of them if I can. You're able to add users and/or groups to a project's Roles, so this is an easy way to manage users and also delegate the management of access to projects to the user community.

RE: #3, there are 3 levels of adminisrator in Jira: System Administrator allows you to do everything, Administrator allows you to do everything except promote others to system-administator level, modify mail configuration and a few other global things, finally there is Project Administrator which allows you to manage Role permissions, Versions and Components on a particular project. Jira is intended to be centrally managed by a small number of admins. It is not intended to have management distributed. My recommendation is to have as few jira-admin and system-admin users as possible. That means that this small group will be the ones that add new custom fields, edit workflows, etc.

We work with many clients to help them make best use of the tools, so if you want some help with best practices or processes, feel free to reach out to me and we can discuss it further.

[Steven F Behnke]

Good detail here Dave

[Deleted user]

As for the workflows, you'll have to decide if you can use common workflows. Or if each project requires a custom workflow. My suggestion would be to keep it as minimal as possible because it will keep maintanence down, but you will need to decide what works best for your project flow. If the project owners can agree on common workflows and consult one another prior to implementing changes, it will help from an administrative perspective. JIRA is a fabulously customizable system, but rash field creation and status creation can result in a spiderweb that makes little sense in the end. So I recommend you evaluate changes carefully. My suggestion is to start with the most basic workflow you can and slowly move to customization at a methodical pace. You'll be a happier admin for it.

[Deleted user]

Dave provides very good detail. One recommendation I would make is to tie default project roles to the appropriate groups. Then when you create projects, the perms will be consistent. Then the admin or project admin can adjust access from there to tailor to that project. Trying to create custom permissions for each project at the time of creation will likely result in holes that you have to analyze to fill. Having known permissions and tailoring them as the need arises will make this process easier.

How you control your permissions is up to you. But I would say if you are using AD, let those groups control your membership. We have an internal user for backup sysadmin if we lose AD connectivity, the rest are AD. We nest our development and other groups/users under JIRA System Administrators, JIRA Administrators, JIRA Developers, and JIRA Users. By doing so, Our AD admin can add new users to a subgroup and they are already have the appropriate permissions in JIRA. We use the same structure for Confluence and Bamboo. This does take the control of user addiotion from the Atlassian Administration, but it's not really a role that I desire. It allows the admin to focus on the best use of the tool, rather than helpdesk tasks that are going to be duplicated otherwise. All permission requests can be handled by our infrastructure team, which is not my function in our organization. Your desired level of control may differ from ours.