Best practices for a user who is a lead developer on one project but a user/observer on another?

[Clarissa V]

My team would like to have the ability to have one user, A, be a lead developer on project X, for example. However, we want user A to not be a lead developer and be a regular developer on project Y. We want the user to have different permissions (closing issues, etc.) on the two projects. Would I simply use a project role for this? I'm trying to figure out what the difference is between a user group and a project role. I understand the role is project specific but the user group is global, but I don't see how a user group would be helpful for us for these kinds of situations.

[Muhammad Ramzan(Atlassian Certified Master)]

From my point of view the best way is to define project roles so you can add users to project roles as per project needs and user needs.

[Joe Pitt]

You can use user roles to do that. I don't like groups for a three reasons. 1. They require the JIRA admin to administer the membership, 2. They often don't give the desired level of control, and 3. Roles allow the project admin to manage the project users. Most old timers don't use groups for those reasons. The other advantage you can have one permission scheme for all projects when you use roles. 

[Clarissa V]

@Joe PittBy user roles do you mean project roles? So that the project admin can add or remove users from specific roles in a project?

[Joe Pitt]

Yes

[Ravi Sagar _Sparxsys_]

@Clarissa V 

Let me try to help using these points.

• Permissions are either global or project based
• Project specific permissions are defined by permissions schemes in Jira. These schemes can be shared, that means two or more projects can have same set of permission.
• Permission schemes have a list of permissions along with who is assigned to those permissions. Now this who could be a user, project role, lead, group, assignee, reporter or watchers.
• Group is a collection of users. It is created and maintained by admins.
• Project role are more or less like team roles. Developers, Testers, Leads. It is created by admin but for each and every project the project lead can manage its own role that means. Lead can add/remove people to these roles.
• Using project role has advantage because lead can add/remove users without asking admins.
• In your case most likely you who need different permission scheme for those two projects (since you mentioned you need different permissions for closing issues etc.)
• You can also have same permission scheme on two projects and have different leads. If you want to have same permission scheme then use project roles or leads wherever possible so that the add/removing people from that role can be delegated to the project lead.

I hope I didn't confuse you further.

Ravi

[Clarissa V]

@Ravi Sagar _Sparxsys_ 

I think for our usage maybe we'd want to be assigning certain users to permission schemes rather than using project roles, correct?

For example, if we have 3 users in a Lead Developer project role, but then in a permission scheme allow the Lead Developer to close issues, that means any of those 3 users would be able to close the issue even if they aren't actually a lead for a project. Correct?

[Joe Pitt]

Project roles are project specific. In project A you make the user a lead developer. Their role in project A has NO effect on their permission in any other project. The long standing security model says you never give individual users access to resources. You give a role or group access to the resource and put individual users in the role or group. In most cases you have many more resources than roles or groups so if a user leaves it is safer, from a security standpoint, to remove them from roles or groups than trying to find all the resources they have access to and remove them from those.