Is it possible to prevent users from verifying an issue, if they resolved it?

[Guido Wilken]

As we are a small group of developers we do not have a dedicated QA team which could be reflected as a group or permission in Jira.

We still want to introduce a "four eyes rule". If someone resolved an issue he should not be able to verify it by himself. Is there a way to reflect this in the issue workflow? I didn't see anything like it....

Thanks!

Guido

[Ramiro Pointis]

Yes, that could be a solution. If you assign to other person and the issue can be resolved only by the assigned user... Yes, that will do the thing.

Or maybe you can set a condition that indicates you need at least a vote for the issue to be closed, so other user or maybe two need to vote the issue before it can be closed.

[Ramiro Pointis]

There is an option to add a condition called 'Value Field'. There you can choose the field 'Votes' and indicate that should be grater than 1

[Ramiro Pointis]

And the voting can be done since the issue is created. I'm using in a issue type called 'Documentation' where the issue needs to have 2 votes to be accepted.

[Jobin Kuruvilla [Adaptavist]]

Good poiint above the 'Value Field' check!

[Jobin Kuruvilla [Adaptavist]]

It comes from JIRA Suite utilities plugin. See https://studio.plugins.atlassian.com/wiki/display/JSUTIL/JIRA+Suite+Utilities+Workflow+Conditions#JIRASuiteUtilitiesWorkflowConditions-ValueFieldCondition

[Guido Wilken]

Mmh, what version of Jira are you referring to? I recently upgraded to v5.0#713. When I add a condition, I have the following options:

	Code Committed Condition
	<label for="com.atlassian.jirafisheyeplugin:no-open-reviews-condition"> No Open Reviews Condition </label>
	<label for="com.atlassian.jira.plugin.system.workflow:onlyassignee-condition"> Only Assignee Condition </label>
	<label for="com.atlassian.jira.plugin.system.workflow:onlyreporter-condition"> Only Reporter Condition </label>
	<label for="com.atlassian.jira.plugin.system.workflow:permission-condition"> Permission Condition </label>
	<label for="com.atlassian.jira.plugin.system.workflow:subtaskblocking-condition"> Sub-Task Blocking Condition </label>
	<label for="com.atlassian.jirafisheyeplugin:unreviewed-code-condition"> Unreviewed Code Condition </label>
	<label for="com.atlassian.jira.plugin.system.workflow:isuseringroup-condition"> User Is In Group </label>
	<label for="com.atlassian.jira.plugin.system.workflow:isuseringroupcf-condition"> User Is In Group Custom Field </label>
	<label for="com.atlassian.jira.plugin.system.workflow:isuserinprojectrole-condition"> User Is In Project Role </label>

[Guido Wilken]

Mmh, what version of Jira are you referring to? I recently upgraded to v5.0#713. When I add a condition, I have the following options:

Code Committed Condition

No Open Reviews Condition

Only Assignee Condition

Only Reporter Condition

Permission Condition

Sub-Task Blocking Condition

Unreviewed Code Condition

User Is In Group

User Is In Group Custom Field

User Is In Project Role

[Ramiro Pointis]

Yes, the 'Field Value' is in the Jira 4.4

Jobin is right, this plugin has the possibility to add the validator. This are the indications to install it, or you can look for it in the Plugin Exchange

To install the JIRA Suite Utilities plugin:

1. Click the 'Administration' link on the top bar to open the JIRA administration console.
2. Click the 'Plugins' link under the 'System' section in the left menu to open the 'Universal Plugin Manager'. The 'Universal Plugin Manager' will be displayed, showing the plugins installed on your JIRA instance.
3. Click the 'Install' tab in the UPM. The 'Find new plugin' page will display, showing the featured plugins available for JIRA.
4. Type 'JIRA Suite Utilities' in the 'Search the Plugin Exchange' box and click the 'Search' button.
5. The JIRA Suite Utilities plugin will appear in the 'Featured Plugins' section on the 'Install' tab. Click the 'Install' button. A confirmation message and the plugin details will display, if it is installed successfully.
6. Restart JIRA.

[Guido Wilken]

Very interesting!

Is it possible to use a variable in the Value Field check?

My idea would be to set the assignee to the user who resolved the issue in a post function and then use the value field check in the verify transition to check, that the assignee field is different from the current user.

That would be perfect!

[Ramiro Pointis]

Oh, I understand now. You want to verify if the user that press the button is the same than the assignee. I'm searching, right now I found this: 'User Is In Custom field' but it only works with Custom Fields, and the assignee is not.

[Ramiro Pointis]

I didn't quite understand. I think that if you resolve the issue you will be the asignee by default, so the assignee would be in fact the current user.

[Guido Wilken]

Exactly.

I just wanted to make sure, that this is really the case by adding a post function. So if someone else resolved the issue than the person who was assigned in the first place.

The more important part would be whether the value field check would be able to compare the current user with the assignee field when someone presses the verify button.

[Ramiro Pointis]

Awesome! That is a good one indeed!

[Guido Wilken]

Ok, I think I got it!

I will use the post function "Update Issue Custom Field" to write the current user into the customfield "resolved by user" when the issue is resolved.

When the issue is verified I will use the "User is in custom field" check to check, that the current user is different than the one in the field "resolved by user".

I'll try that right now and let you know...

[Jobin Kuruvilla [Adaptavist]]

If you intend to make sure the assignee is changed when you Resolve the issue, use the 'Field has been modified Validator' in the JIRA Misc Workflow Extentions plugin.

[Guido Wilken]

Mmh. It's not working out :(

If I use a read only text field, the "User Is In Custom field" Condition is not working. The description of the condition suggests, that it's only working together with user picker fields.

But if a change the type of the custom field to user picker, it's editable, which makes the whole process unusable, as anyone might change the field and than verify the issue...

Is there a way to make a custom field read-only? Then I might be able to use the user picker :)

[Ramiro Pointis]

I'm only familiar with the type of custom field 'Read-Only Text box'. In the other hand, if you have a normal textbox customfield but it isn't in the edit issue screen, then no one can change the value inside that custom field.

[Jobin Kuruvilla [Adaptavist]]

You can add ny step in the workflow you want. But the default workflow itself covers this is a small way. There are 2 steps, 'Resolve Issue' and 'Close Issue'. The person who actually fixes the issue 'Resolves' it where as another one, normally the one who reported it or a tester, verifies the issue and 'Closes' it.

To add a 'Verify' workflow action is pretty common too!

[Ramiro Pointis]

Ouch! I forgot about the 'Close' and 'Resolve'. It is much easier that way! Good one!

[Jobin Kuruvilla [Adaptavist]]

@guido might also want to add some conditions etc which prevents the person who resolved it to close it as well. Maybe add a post function in the 'Resolve' action to assign it to someone else and then allow only the assignee to 'Close' the issue.

[Guido Wilken]

Mmh, I don't see any condition to check for votes.

And as well, the voting is usually done before resolving the issue, right?

[Guido Wilken]

If I add a rule to assign the issue to another user it would be the same as having a role for this, or am I wrong?

Because I would have to choose the user in the rule...

The idea with the voting seems very interesting!

I'm checking the configuration right now... Just a sec ;)

[Jobin Kuruvilla [Adaptavist]]

There is no default one for voting. You will have to create one yourself. A good idea neverthless.

Regarding assigning, you can let the person who resolve it choose the assignee by adding it on the resolution screen or configure a predefined assignee in the post function. Configuring any rules would need additional dev work.

[Ramiro Pointis]

Hi Guido,

I found a condition that could be very useful. It's called 'Separation of Duties Condition'

And this is the description: Condition to prevent a user to perform a transition when he has already performed another.

Take a look when you can. I think this is what you are looking for ;)

[Ramiro Pointis]

Let know if you found the solution to this issue.

[Guido Wilken]

unfortunately it's not working yet.

I won't be able to continue testing until Monday...

I'll keep you posted!

[JamieA]

If you don't want to dick about with custom fields, you could use the scripted condition from the script runner plugin. The actual condition is below.

import com.atlassian.jira.ComponentManager

def componentManager = ComponentManager.getInstance()

def resolutionRecords = componentManager.getChangeHistoryManager().getAllChangeItems(issue).findAll {
    it.field == "resolution" && it.fromValue == null && it.toValue != null
}
return !resolutionRecords || resolutionRecords.last().user != componentManager.jiraAuthenticationContext.user?.name

[Ramiro Pointis]

Yes there is. You can configure it in the workflow in many ways. For example:

-You can have someone in a QA rol inside the project who is the only that can approve the issue.

-You can set up a condition that only the project leader can approve the issue.

Here is a doc where you can find out how to configure the workflows, but I think Atlassian is having trouble in the confluence pages.

[Guido Wilken]

Thanks guys!

What I actually want to achieve is, that I don't need specific roles or permissions for people who are able to review bugs. That's what I currently have...

We have a team of 5 people working on a project and everybody should be able resolve AND verify. The only thing I want to prevent, is that the same person who resolved an issue is able to verify it.

Thus having at least 2 persons taking a look at each issue without specifying a specific QA role...