Why does the global automation rule change the assignee?

[Diskonekted]

I'll be succinct, I have automation rules for both projects and global.

For Projects, I have rule created every day and assigned to me - but due to the trigger being a schedule (I.e. every 1 day) - I'm unable to perform a transition within the same rule.

For Global, I have one rule that transitions the automatically created Jira tickets to the 'In Progress' status.

Problem is that when the global rule runs - it changes the Assignee, despite this not being a condition/instruction of the rule-set.

See below:

[Diskonekted · Accepted solution]

For completeness & visibility for others who have the same experience, I worked-around the issue by adding in a new action to the end of the global rule. See below:

Still, would be good to understand why this was occurring in the first place.

[John Funk]

I don't see any reason why it would be reassigning unless there is a post function or some other automation rule. Does the reassignment show in the History for the card? (It should) and who does it say is changing the Assignee?

[Diskonekted]

@John Funk , it does show in the Activity - History section of the card. Interestingly the reassignment happens before the transition action - so almost by having the rule start execution it performs the reassignment.

As per the above screenshot, the rule then reassigns to me.

[John Funk]

I would say you have another rule running somewhere that does that. 

[Diskonekted]

@John Funk  where would be the place to confirm this?

I've looked in the Automation Rules Audit Log and this is the only rule which has that Task as the Associated Event.

Additionally, it would be good for someone else to test this setup.

As noted above, I can:

• Switch off this rule and the original assignee is retained.
• Copy the rule and make it project specific, the original assignee is retained.

Many thanks to you all.

[John Funk]

Maybe @Simmo can shed some light. He is a good light shedder.  :-)

[Simmo]

Hey guys,

The best place to check this sort of thing is in the global admin section. Have a look at the all rules tab. 

OR, if you can reproduce it reliably, reproduce it then got to the global admin and click on audit log. That'll show you all the rule executions and hopefully point out the offending rule.

[Diskonekted]

@Simmo  when you say global admin section are you referring to Settings > System > Automation Rules?

If so, that's where I pulled the audit log for the global rules from - refer to my post on //13-10-2020.

Regarding the site audit log (Settings > System > Audit Log), I'm using only the freemium version of the cloud offering so don't get this option to troubleshoot.

As noted before, it's pretty basic setup - would be easy for another person to confirm/deny if it's replicable outside of my efforts.

I can certainly replicate it, but it would be good for someone else to do it as to eliminate me from the potential factors at fault :)

[Simmo]

Hi @Diskonekted ,

That's right, Settings -> System -> Automation Rules. Inside the Automation screen you'll see this:

That is the global admin. All rule executions will show up here, which will then make it easy to narrow down your case :)

Cheers,

Simeon.

[Diskonekted]

Right.

See my last post back on 13-10-20 where I note this already.

Thanks anyway.

[agustin]

+1 to this issue. went to Settings -> System -> Automation Rules -> Audit log.

Below 2 screenshots showing the behaviour and logs after I turned on the rule/

I'm guessing there's either a bug, or there's an old general rule/post function that doesn't fall in the Audit Log of Automation. @Simmo 

Thanks @Diskonekted for the workaround, worked like a charm, I've read and tried other posts with no luck.

[Diskonekted]

@agustin , no worries.

Somewhat reassuring (for me) that others are having the same issue and that the community can assist each other to overcome this.

[Kanishka Karunanayake]

Happening for me too, definitely no other automations running, clearly a bug.

Will try workaround from @Diskonekted , thanks for that!

[Diskonekted]

Hi @Kanishka Karunanayake ,

This was quite the blast-from-the-past; I'd long since forgotten about this bug.

Fingers crossed the workaround solves the problem for you.

Cheers,

D

[Kanishka Karunanayake]

@Diskonekted - it worked a treat, so one less Jira bug to worry about, ta!

[Diskonekted]

@Kanishka Karunanayake , great to hear. :)

[Diskonekted]

Hi @John Funk ,

Apologies for not being clear - I can perform the transition within the one rule, but it requires me to use some JQL, which I don't want to do right now. So instead I've opted for the two rules.

Regarding the post function; there are none. When the rule setup is like below the assignee is retained:

Project 1 - Rule 1: Every day create task for Joe Bloggs.
Project 1 - Rule 2: Transition automatically created rules to 'In Progress'

But when the below setup occurs, the assignee changes:

Project 1 - Rule 1: Every day create task for Joe Bloggs.

Global - Rule 1: Transition automatically created rules to 'In Progress'.

* All tasks are now assigned to 'Automation for Jira'.

Again, suspect this might be a bug - but grateful if others can test this setup to see if it's common across other subscriptions (my Jira cloud instance is default out-of-the-box).

[John Funk]

Hi @Diskonekted  - Not sure I completely follow what you are asking, but let me see if I can help. 

First, when you say that you cannot transition issues because it uses the Scheduled trigger, I don't think that is a limitation as I perform that functionality with some of my rules. What error are you getting or how is it not working? 

On the second part, since the transition is successfully happening (and it isn't in the Scheduled trigger) there must be a post function in the workflow on the transition to In Progress that assigns the issue. There is no separate functionality that would fire in Automation to assign a user based on whether it is a Project or Global rule. You should check the post functions in the workflow. 

[Diskonekted]

Further note, have tested this with the Project specific rules, by turning the global one off - the issues created within the projects stay at the specified assignee.

Not sure if this is part of how global rules are intended or if this is a bug; could probably work-around this by setting a transition rule for each project or further conditions on the global - but wanted to see if others are having this same experience.