How can I restrict Assignee based on the Assignee of a previous Status?

[Dani Lynch]

I need to enforce a maker/checker restriction for assignees. For example, the Assignee in Status A will be completing the task and the Assignee in Status B will be reviewing their work. I have a regulatory requirement where an individually cannot review their own work, so looking to enforce this either through the workflow or a behavior. The group of assignable users in Status A and Status B are the same. I have written a post-function from Status A to Status B that clears the Assignee field but I can’t figure out where to start with restricting the available assignees

[Matt Parks · Accepted solution]

Do you have any plugins installed? If you are using Scriptrunner and you're changing from Status A directly to Status B, you can choose to not clear out the Assignee but then use the 'Field(s) changed validator' as a new validator on the workflow transition and put in the Assignee field. This will force them to set a different Assignee.

[Dani Lynch]

Hi Matt, 

Yes I have Scriptrunner. I can get the field value to change but the concern is restricting someone from editing the issue (not on a transition) while it’s in Status B and updating to the Status A assignee. Is there a way to enforce that with a property or behavior? 

[Matt Parks]

I don't know whether you can do it with a property (my knowledge in that area is pretty limited), but you can do it through a behavior.

Just create a new behavior and map it to the appropriate project/issue type.  From this point, you have two options:

1. Add in the Assignee field and set the Guide Workflow to the workflow name for the issue type.

Note that if you have multiple issue types where you want to do this that are not using the same workflow, you'll have to create a different behavior for each workflow if you use this option.

Set the option that the field is read-only and then add a condition that the Workflow Step is Status B. You will also need to add an exception condition so that it doesn't apply when you are executing a Workflow Action that matches the transition from Status A to Status B.

2. Add in the Assignee field and use the following script in the behavior. This option will work on any issuetype/project mapping that uses that Status name.

import com.atlassian.jira.issue.Issue

def assigneeField = getFieldByName("Assignee")

def issueStatus = underlyingIssue.getStatus().name

assigneeField.setReadOnly(false)

if (issueStatus == "{Name of Status B}")

{

    assigneeField.setReadOnly(true)

}

This will prevent the Assignee from being updated while the work item is in Status B.

[Matt Parks]

Here's a screenshot of what option 1 could look like.

[Nic Brough -Adaptavist- · Accepted solution]

Welcome to the Atlassian Community!

You can do this if you are ok to do it by status.  The trick is that the assignee field is controlled by permissions.  To be listed in the assignee field, a user has to be granted the permission "can be assigned" in the project.

But your workflow can override that - you can add properties to a status in a workflow that change the permissions - see https://support.atlassian.com/jira-cloud-administration/docs/use-workflow-properties/

[Dani Lynch]

Hi Nic, 

Thank you for that suggestion! This seems to be getting me closer in the right direction but it is still not functioning properly for what I need. 

I believe I need to begin with Jira.permission.assignable but I’m not sure what I would set as the user&value. The team needs to still be able to set an assignee manually to anyone except the individual that was assigned in Status A so I don’t have a static list of users that will only be completing the task and those that will only be reviewing. 

Any thoughts? Thanks in advance

[Nic Brough -Adaptavist-]

I can't think of a way to exclude an individual like that.

[Dani Lynch]

For those that may have a similar requirement/issue, I was able to implement by a combination of the two responses. I added a post-function from Status A to Status B that changes the assignee based on a different user picker field (Secondary Analyst). The Secondary Analyst cannot be the Assignee. I added a Scriptrunner behavior using option 1 of Matt’s suggestion and also added a workflow property “Jira.permission.assignable.denied” on Status A

NIc, Matt, thank you for your assistance!