Separate groups in jira

[Rich Stephens]

I am new to using/configuring Jira. We have a single Jira license, but I have a requirement to configure Jira so that 3 separate groups of developers have separate workflows, projects, and issues, almost as if they had completely separate instances of Jira (although there is truly only 1) - I.E a user logging in under "group 1" would ONLY be able to see projects and issues for "group 1", and would have a default workflow that can be different than that for "group 2" or "group 3".

Is there a relatively simple way to set this up? Is this even possible at all with Jira security? If so, is there a step by stop guide somewhere that could guide me through setting Jira up this way?

Thanks,
Rich Stephens

[Jim Birch · Accepted solution]

Users can be created manually by the admin, self-created (could be dangerous), or can be sucked from an LDAP repository, eg, Active Directory. Groups can be created by the administrator, or sucked from LDAP. LDAP groups will have their membership taken from LDAP; manual groups have members added by the administrator so require more management. LDAP is the way to go if your users and groups are defined elsewhere.

A set of project roles are defined once that are global to the Jira instance. Jira comes with a default set but you probably want to change these. For example, our project roles are (simplified) Administrators, CoreTeam, Friends, Commenters, Viewers. In this example, Administrators can do anything, including add users to roles and edit to the project definition, CoreTeam can do anything to issues, Friends get most issue functionality but can only edit their own work, Commenters only comment, Viewers are read-only users. Figure out what user roles you think you need. You can enhance or change the entire system as things evolve but remember roles are global to the Jira instance.

Each project uses a specified Permission Scheme. The schemes are reusable and multiple schemes can be defined for different types of project but you may find that one scheme can be used for all, or most of, your projects. Schemes are quite flexible. The basic keep-it-simple-stupid approach is to assign a permission set to each project role. You then add users and/or groups to the roles in each specific project. So you could be (eg) Admin in one project, Coreteam in another and be in a group that has view-only access to another set of projects.

There about thirty permissions but the trick is to combine them into useful sets for each role. See this page for a list of permissions:

http://confluence.atlassian.com/display/JIRA/Managing+Project+Permissions

This approach provides a simple solution to common needs of in-house access management but it's possible to do all sorts of weird things in Jira, eg, define a "client" role could be set up that only sees issues that the client created himself.

You probably need get your head down and create some test stuff to get a feel for how these concepts work in practice. You are very unlikely to get it all right up front so do some testing, and thinking.

[Jo-Anne MacLeod]

Yes, this is easily done. Take a look at the permissions scheme. Basically you would set up the users into JIRA groups as appropriate. Then give the groups the proper permissions using the permission scheme and then assign each permission scheme to the appropriate project.

Do you need more details?

[Rich Stephens]

Yes, please. I'm new to configuring Jira so any details you could provide would be of great help.

[Jim Birch]

The normal and simple way to do this is to have separate projects. Each project can have a different workflow and a different set of users. Issues can only be created in the project by authorised users and get the appropriate workflow.

It is also possible to have different workflows for different issue types and use various other controls like validation functions in workflows to "micromanage" things but this quickly starts to get very complex and hard to maintain and change (or even understand.)

[Rich Stephens]

That makes sense - it actually pretty much sounds like my description of the problem - I just need more detail on how to set up the permission schemes/groups/users to do this.