Can I exclude the assignee in a User Picker custom field?

[Shawn Hays]

Basically, we have a set up now where we have a peer review field, but you can select the assignee of the ticket to peer review the code. we'd like to be able to not be able to choose the assignee as a potential peer reviewer.

[Dieter · Accepted solution]

A straight forward solution would be to write a Groovy validator which checks if the peer reviewer custom field value is different from the current assignee.This would have to be done in a transition that selects the peer reviewer. Of course the peer reviewer should not be on any edit screen so noone can bypass this business logic.

Another completely different but IMO interesting approach is to use the separation of duties condition provided by this plugin https://studio.plugins.atlassian.com/wiki/display/JMWE/JIRA+Misc+Workflow+Extensions+Documentation#JIRAMiscWorkflowExtensionsDocumentation-SeparationofDutiesCondition%28newin1.1%29 E.g. If you had two transitions "accepting development" and "review" you could make sure that transition "review" always has to be executed by a different user than "accepting development" thus assuring the 4 eyes principle.

This might also be an alternative if you don't want to start Groovy coding or you can't since you are on OnDemand. This platform provides the JMWE plugin but not Groovy

[Stephanie Gutierrez]

How were you able to set up a peer reviewer field?

[Dieter]

A straight forward solution would be to write a Groovy validator which checks if the peer reviewer custom field value is different from the current assignee.This would have to be done in a transition that selects the peer reviewer. Of course the peer reviewer then should not be on any edit screen.

Another completely different but IMO interesting approach is to use the separation of duties condition provided by this plugin https://studio.plugins.atlassian.com/wiki/display/JMWE/JIRA+Misc+Workflow+Extensions+Documentation#JIRAMiscWorkflowExtensionsDocumentation-SeparationofDutiesCondition%28newin1.1%29 E.g. If you had two transitions "accepting development" and "review" you could make sure that transition review always has to be executed by a different user than "accepting development" thus assuring the 4 eyes principle.

This might also be an alternative if you don't want to start Groovy coding or you can't since you are on OnDemand. This platform provides the JMWE plugin but not Groovy

[Ramiro Pointis]

I'm not sure I understood, but basically you want that other person than the assignee would be able to resolve an issue? If that's the case you can Grant or Deny Permissions on the Permission Scheme in every project.

I always recommend to configure the Permission Scheme with Roles or Group of users instead of users directly.

[Ramiro Pointis]

I think this question will be very helpful for you. Take a look at it, there are many solutions to a problem like this one.

[Shawn Hays]

It's more that we want to exclude the person assigned to the ticket from even being able to be selected as the peer reviewer.

Basically make it so there's no option to peer review their own code.