It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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.

3 answers

@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

@Ravi Sagar -Adaptavist- 

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?

Like Ravi Sagar -Adaptavist- likes this
Joe Pitt Community Leader Sep 16, 2019

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. 

0 votes
Joe Pitt Community Leader Sep 13, 2019

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. 

@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 Community Leader Sep 13, 2019

Yes

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.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Jira

Demo Den Ep. 7: New Jira Cloud Reports

Learn how to use two new reports for next-gen projects in Jira Cloud:  Cumulative flow diagram and Sprint burndown chart. Ivan Teong, Product Manager, Jira Software, demos the Cumulative ...

365 views 1 3
Join discussion

Community Events

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

Events near you