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.