Automation for jira on comment but not from transition

[Per Kafka Thygesen]

Hi!

I have an issue that I dont really know how to solve!

I am using the addon Automation for Jira, and have a rule that should whenever a issue is commented, and match some certain statuses, be transitioned to a specific status.

However, I dont want to run this rule of a user adds a comment to the issue while its being transitioned. (Eg from a transition screen).

I dont want this, because the jira transition first moves the issue to the new status, and then adds the comment. After that, the rule is run, and it detects the comment and transitions is back to the original status.

Is there any way to prevent this?

[John Funk]

Hi @Per Kafka Thygesen ,

Can you share a screenshot of your rule? 

It might be that you need to trigger the rule on something different or not allow a comment to be added during the Transition. 

[Per Kafka Thygesen]

Hi John_Funk!

My rule is pretty simple and looks like this:

The use case in this instance is:

1. Support issue is in status "Waiting for Support"

2. Supporter want to send a reply to the customer, so a transition is used to transition the issue to status "Waiting for customer". And he adds a comment in the transition screen.

3. The automation rule transitions the issue back to "Waiting for fupport"

The rule exists to transition issues to "waiting for support" when customers and internal users leaves comments on an issue.

[John Funk]

Not sure why the rule would fire if the system first moves the the issue to Waiting for Support and then adds the comment because the your condition does not fire if the status is Waiting for Support. But obviously it is doing that. 

I am wondering if you could set another field value somewhere and use that as part of your condition statements. It seems to be a timing issue where Automation is firing before other steps are competed. 

Or maybe add a new condition for User condition and check to see if the one who submitted the comment is in a particular group (like support or even just Jira users). 

[Per Kafka Thygesen]

I think you might have read my description incorrectly. The issue is not transitioned to "Waiting for support". It is transitioned to "Waiting for customer".

So operation looks like this:

1. Issue is in status "Waiting for support"

2. User transitions issue to "Waiting for customer" and adds a comment in the transition screen.

3. Automation picks up the added comment, and transitions the issue back to "Waiting for support"

I imagine that this happens because the transition changes the status to "Waiting for customer" and then adds the comment. So when the automation rule runs, the status is "Waiting for customer" and not "Waiting for support".

I have a temp fix in place right know, that checks if the issue has been transitioned within the last minute, if so, do not run the rule.

I am just not satisfied with needing to have a date check to prevent this issue from happening.

[John Funk]

I might have phrased it wrong, but I understood what was happening.  :-)

Did you consider either of the two suggestions I mentioned above?

[Per Kafka Thygesen]

I though about your suggestions and I am not sure that they are suitable for out situation.

1. Setting a field would be cumbersome since it would involve setting it on many different transitions and then rely on the automation rule to set it back to empty. But besides the management issue, I think it might work in practice.

2. Checking for a specific user group does not work for us, since we need to differentiate between if a comment is set via a transition or not. And not what user added the comment.

[John Funk]

You would use number 2 in conjunction with the status - in other words, two separate conditions. 

[Paul Krueger]

What about only reactivating the issue when the initiator is the issue reporter?

[John Funk]

That looks good! Give it a try!

[Per Kafka Thygesen]

Hi Paul and John!

Unfortunately that above solution does not work for us, since we need the issue to transition for all users not only the reporter.

Currently I am running with the below solution, I do not think it is ideal, but it seems to be working out for now.