Negative condition in transition change

[Satish Kumar Jayaram]

Is it possible to set up the following condition in JIRA in Transition change

All of the following conditions

Only users in group xxxxxgrp can execute this transition.

Only NOT the reporter of the issue can execute this transition.

which means, can we add negative condition in changing one transition to another

[Ramin Ghanbari]

Hi,

This add-on does the job.

adaptavist ScriptRunner for JIRA

Just need to add the following condition to the transition:

[Satish Kumar Jayaram]

thank you for your support, I'll close this thread now.

[Nic Brough -Adaptavist-]

I'm afraid Jira doesn't have negative conditions really.

Your options are all going to need a bit of code, which you can probably do with the script runner plugin if you don't want to write your own plugin.

Option 1 would be a new "condition" of "not reporter". That would stop the user being offered the transition

Option 2 would be a validator that says "if current user = reporter, then fail validation". That would let the user into the transition, and return them to the transition screen with a message like "Sorry, you are the reporter, so you can't approve this".

- D'oh! Just noticed "OnDemand". Where you can't install script-runner or your plugin

[Satish Kumar Jayaram]

Can we set up the validation depend upon the value of other fields?

Example:

Transition from Open -> Approve should happen only if the Resolution == "Fixed"

[Nic Brough -Adaptavist-]

Yes, but that won't work in this case. That condition requires the resolution to be set when the issue is open, which is not really going to happen in any sane setup

[Satish Kumar Jayaram]

Sorry, my last question is not for this case. It was a different one. Regarding the negative check validation, I agree with your limitation and will convey it to my team and I'll close this loop.

Regarding my 2nd question, could you please tell me how could we show a transition button to group of users only if the resolution status is "Fixed"?

[Andris Grinbergs]

You should add 2 conditions:

1. User Is In Group
2. Value Field (Resolution = Fixed) or (Resolution = 1)

[Satish Kumar Jayaram]

Andris,

I couldnt find the Value field in the list of conditions. Are you sure we can do this in OnDemand?

We are able to see only the following fields

Code Committed Condition

Complete Session Condition

No Open Reviews Condition

Only Assignee Condition

Only Bamboo Notifications Workflow Condition

Only Reporter Condition

Permission Condition

Sub-Task Blocking Condition

Unreviewed Code

User Is In Group

User Is In Group Custom Field

User Is In Project Role

[Nic Brough -Adaptavist-]

You might want to try enabling the "Jira Suite Utilities" - there may be a function in there that handles the condition you're talking about.

However, I'll say it again, it's probably not going to work for you.

Think through what a condition does: It looks at the issue data and says "you can only use this transition if you meet this rule". If you set up a rule of "resolution must be X", then the resolution must be set on the issue BEFORE you can start the transition. It's very rare to have a resolution set when an issue is "open" because Jira considers anything with a resolution to be closed.

As I suspect you want "open" to genuinely mean "open", your condition is going to completely block your transition from being offered to the user, because the resolution will NOT be set. Ever.

[Peter Van de Voorde]

Satish,

Why do you want everybody in that group except the reporter be able to do the transition?

I don't understand your use-case.

I would simply remove the reporter from the xxxxgrp and say only people in this group can execute the transition.

Best regards,

Peter

[Satish Kumar Jayaram]

Consider the following scenario

1) Creator -> Creates the ticket, status = Open

2) Approver - > Approves the ticket , status = Approved

apparently creator and Approver and rest of the team are peers and share the same group.

It is known that creator cannot approve his own ticket, at the same time the unassigned ticket can be approved by any other peer, by assigning it to themselves.

How do we handle this scenario?

[Peter Van de Voorde]

Satish,

I would handle this with training instead of trying to enforce it in the tool.

Simply teach your people not to approve their own tickets.

Like Nic mentioned: there isn't really any option to do this without resorting to custom scripting, which isn't possible in OnDemand.

Best regards,

Peter