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

Danielle Lynch February 16, 2024

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

3 answers

2 accepted

0 votes
Answer accepted
Matt Parks
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 16, 2024

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.

Danielle Lynch February 16, 2024

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
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 16, 2024

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
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 16, 2024

Here's a screenshot of what option 1 could look like.Assignee Read Only Behavior.png

0 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 16, 2024

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/

 

Danielle Lynch February 16, 2024

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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 16, 2024

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

0 votes
Danielle Lynch February 21, 2024

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!

Suggest an answer

Log in or Sign up to answer