I am getting confused.. or perhaps I was confused to start with regarding groups and roles. I am not sure I am seeing the benefit of both at the moment.
Currently we use ClearQuest. Everyone has a 'role' assigned by group(s) when they log in.... and I guess I could do the same using groups in JIRA. However I could also create roles at a project level and assign users that way to pretty much the same result.
Our defects are categorised according to application and application sub-area. These I am thinking represent Projects and Components in JIRA. However these 'projects' dont match with our real live projects so the concept of having a team lead etc for the project in JIRA doesnt seem to make sense. Although we do pull defects into these live projects as we go along. This suggests to me I am best using groups only so that roles are given to individuals across all projects rather than use roles. Am I missing something? Will I loose out buy setting it up this way?
All of that said we are going to roll this out to other sites who will have a distinct set of users and people who tend to work on a single project.. so perhaps thats more suited to roles?
I also have a nag that if at a later date we looked at using Greenhopper instead of our current project management software (v1) then it seems there might be an expectation that the real live projects match those defined in the bug tracking... is that the case? I have also made an assumption that I can selectively pull in bugs to V1 projects from JIRA is that correct viz... this bug to that project in V1
If anyone(s) can help clarrify these troubles it would be brilliant as I am going mad with the possibilities
Previous answer by Srini is pretty much correct but I thought I would add some additional information.
The easiest way to think about this is that Roles = a set of permissions and Groups = a set of people. There is a pretty good explanation of this in the answers to this question in Stack Overflow:
RBAC has to do with security (e.g., permissions) and groups are just a way to collect people. However, in a lot of places it is tedious to assign roles to individuals so they end up putting people in groups and then assigning the groups to roles. Which can be dangerous from a security standpoint if groups get used across roles, applications, etc.
Note that in JIRA, the roles themselves are global and show up on all projects whether they are used in the permission scheme associated with that project or not. So, there is some potential for confusion if a project admin puts someone in a role and doesn't realize that the role wasn't put into the permission scheme. Project admins can't change permission schemes, only JIRA admins can do that. A project admin can view the permission scheme but they don't always do that.
We've ran into some of those issues and we are currently in the process of defining a set of Roles that get used uniformly across all projects in the permission schemes so we can reduce some of the confusion.
* Difference between Project Role and Group - Project Role can be administered by Project Lead and Groups can only be administered by Administrator (adding/removing users)
Tips for your questions
1. Don't user default groups in Jira in group/project roles, create group/project role as needed
2. What I basically do - group users based on Site - group name can be [make the group name meaning full by prefixing country-location-etc.] This group might sound extra work but will help you fine grain the access further
3. Create project Role and assign what permission the users needs in the project - Make the Project Role name meaning full [ProjectKey-WhatIsThePermission]
4. Project Lead can add/remove user as required and your jon will be reduced when managing huge instance of Jira
Hope this help
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events