Allow asignee to modify issues only if they are part of a group

[Andrea Gagliardo]

Hello everyone!

I am trying to figure out how to solve this problem:

let's say that there are 2 users (user 1 and user 2) that are part of 2 different group (group A and group B). I have issues one issue (task 1) assigned to user 1, and one issue (task 2). There is a task 3 that is not assigned. So the situation is:

• Task1 assigned to user1 (part of group A)
• Task2 assigned to user2 (part of group B)
• Task3 not assigned

I would like that (from the user point of view):

• user1 can modify only task1 (because is assigned to that)
• user2 can not modify anything

I would like that (from the tasks point of view):

• Task1 modifiable by user1 and admin
• Task2 modifiable only by admin
• Task3 modifiable only by admin

Task1 can be modified by the assignee because the assignee is in the group A. So let's say that group A represents users that can modify issues that are assigned to.

Task2 can not be modified by the assignee because the assignee is in not in group A.

I want to implement these restriction for few reasons:

• I need to assign people to tasks to do resource allocation
• Some people have to manage the work that are assigned to (start date, due date and status)
• Some people need just a read-only mode

Right now i am trying to play with the Permission Scheme, but i can not figure out how to solve my problem...

Thanks in advance!

Andrea

[Andrea Gagliardo · Accepted solution]

@Trudy Claspill set me on the right path, I leave here exactly what I have done.

1. In the permission schema I set the ability to Edit Issues to assignee and admin
2. In the Workflow i added the property 'jira.permission.edit.group' (to all status) with related group id to allow the specified group to edit

I discovered that using 'jira.permission.edit.denied.group' with the group id that i dont want to be able to modify does not work as intended, but just deny to anyone the ability to edit (maybe the .group does not work here...).

Another thing that I learn is that if you add a 'jira.permission.edit.group' will automatically be in AND condition with the permission scheme, so you remove the edit capability to any user/group that is not specified. 

[Trudy Claspill · Accepted solution]

Hello @Andrea Gagliardo 

Welcome to the Atlassian community.

You said Task 1 can be modified by its Assignee, but Task 2 cannot. How do you determine that? Is it based on their group membership? Can the Assignee modify their tasks only if the are a member of group A?

What modifications are and are not allowed? Commenting? Transitioning the issue to another status? Reassigning the issue? Editing other fields in the issue?

I don't think you'll be able to meet your requirements by modifying the permissions. You might be able to do so through Workflow  Properties.

https://support.atlassian.com/jira-cloud-administration/docs/use-workflow-properties/

Can you tell us more about why you want to implement these restrictions?

[Andrea Gagliardo]

Thanks for your reply! 

Task1 can be modified by the assignee because the assignee is in the group A. So let's say that group A represents users that can modify issues that are assigned to.

Task2 can not be modified by the assignee because the assignee is in not in group A.

I want to implement these restriction for few reasons:

• I need to assign people to tasks to do resource allocation
• Some people have to manage the work that are assigned to (start date, due date and status)
• Some people need just a read-only mode

I will add this to the initial post.

[Trudy Claspill]

The Permissions will apply to all issues in the project.

So, for example, if you restrict the Edit permission to the Administrator project role and the Assigned, all Assignees will be able to edit the issues to which the are assigned.

It is not possible through the Permissions to enable some Assignees but not others to edit their assigned issues based on group membership.

Project permissions are additive. You specify who should have them. You can't directly specify who should not have them. People will not have permissions based on their absence from the permission.

Some Permissions apply to specific "edit" options, like transitioning issues. You can learn more about project permissions here.

https://support.atlassian.com/jira-cloud-administration/docs/manage-project-permissions/

That page includes links to more pages with more detailed information.

You could use a combination of Permissions to grant permissions additively, and then use Workflow Properties to restrict the permissions. For example you could grant the Edit Permission to the Assignee and the Administrator role, and then use the Workflow Properties to restrict that to the Administrators role and members of Group A. So a person would have to be the Assignee or Administrator pet the permissions, and would have to be an Administrator or member of Group A per the restrictions in the workflow properties

[Andrea Gagliardo]

Thanks a lot for the detailed explanation! I will now give it a try.

Have a great day!

Andrea

[Bert Dombrecht]

Hi Andrea,

I think Trudy's reply is the best route to go down: 

• Group A can be project Role "Users"
• Group B can be project Role "Guests"

You need the edit permission to be granted to "Current Assignee" and "Administrators" but then you need to restrict that permission to only members of a project Role "Users" and "Administrators" on your workflow statuses.

However, to make it simpler, perhaps it is an option for you not to set people that should not edit a work item as the assignee?

If you think of the assignee as the person that is responsible for getting the work item to the next status in the workflow, being assignee but unable to edit a work item seems contradictory.

So you could:

• Configure only the project role "User" (group A) with the "Assignable User" permission
• Add the edit permissions to "Current Assignee" and project role "Administrator"
• Configure the project role Guest (group B) with only "Browse Projects"

As a result:

• A work item can only be assigned to you, if you are in group A
• You can only update a work item if you are the assignee, or an admin
• Group B has read-only access

To map a work item to a Group B user, you can use a user picker custom field (for example: "Guest" or "Stakeholder"). So you can still get a list for, or filter a board on work items that reference a specific user from group B.

[Andrea Gagliardo]

Thanks for your idea, but i need to assign tasks to people to take into consideration their workload and to schedule the production plan. So assigning people (even from group B) to tasks is a must. 

Another point is that I'd prefer not having a lot of project roles because is not easily scalable from my point of view, having to create/add new project role for each new permission/restriction seems not the best way to go.