For those of us who have been doing this for a while, we have learned that there really is a right way and wrong way of working with users and groups. While working on the JIRA certification exam, however, I discovered that there is no published documentation on the subject. So consider this a permissions best practice article from someone who helped write the certification.
As a tl;dr, you should use roles whenever possible. With that established, I’ll go into a bit more detail.
In a project permissions scheme, we have the option of adding to an individual permission either a username, a group, or a role. With a small instance, there’s a lot less trouble doing this any way you want, but as your JIRA system grows, it becomes much more problematic if you don’t do this right. Right and wrong, in this case, is defined by which method is easiest to manage going forward, and an important part of management is auditing.
Someday you may be asked what permissions an individual has in JIRA. If you have added individual usernames to permission schemes in JIRA, there is no good way to get this information from JIRA without using third-party add-ons.
We can, however, easily see what groups a person is a member of. Therefore, auditing is made much easier by putting people into groups, and then using groups for permissions.
If we go the route of using groups and permission schemes, though, that then puts all the work of managing project access onto the JIRA administrator. And because most organizations only have one JIRA administrator, and typically JIRA is just one part of their job and they may have other tasks that also demand their attention, it would be even better to configure JIRA in a manner that lets us delegate work where possible.
Roles should always be the preferred method for granting permissions, and ideally the roles would only contain groups, not users.
To that end, instead of using groups and permission schemes, we want to use roles. This allows us to build a much more generic permission scheme that can be used for multiple projects, and it delegates managing the membership of roles to the project administrators. As the JIRA administrator, we will still be responsible for building the permission scheme, associating the permission scheme with the project, and adding users into groups. But the various project administrators (of which there tend to be many more than there are JIRA administrators) can then add or remove groups from the project roles.
We should train project administrators to use groups instead of individual users whenever possible, but it is much easier to audit role membership than it is permission scheme membership.
Pretty much the only time that I want to put a group into a project scheme is for the project administrator permission. Here, I will often add the jira-administrator group, because invariably we are going to be asked to help with the project at some point, and having access by default just makes that process a lot faster. You could add this group as a default member to the Administrator role in the project, but since project administrators can’t change permission schemes, I prefer to have this hard coded into that scheme.