nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira Automation Error with Executing User

unknown

Hallo,

i have an Automation Rule in one of our Jira Projects, that is executed as the triggering User.

Screenshot 2021-02-16 081800.jpg

As the Screenshot above shows i would expect the rule to default back to the Automation User if the User doesn't have the Permissions to execute a certain part of the rule.

Recently i found out, this defaulting back doesn't work. So the Rule throws an Error instead of executing or even checking the Steps in the Rule.

I was in contact with Atlassian Support about this (thanks Ana) and it seams this Problem wasn't reported very often yet.

If you have this Problem yourself or you can reproduce this Problem and think you need a fix, please follow and vote on this Bug:

https://jira.atlassian.com/browse/JSDCLOUD-9733

Thanks

Best Wishes
Michael

Accepted answers

All comments

Hana Kučerová

Hi @[deleted]

thank you for sharing! I didn't know about this one.

Taranjeet Singh

Thanks for sharing, @[deleted]

This is helpful!

Simmo_9kntn7

Hi @[deleted]

The info panel here is perhaps misleading. There are certain users that the security restrictions stop us from running as altogether. In the case of one of these users we'll fall back to the Automation user when we start executing the rule and that is what the info panel is all about.

This is different to the case that you are describing in that we can run the rule as the particular user but there are some security issues. In that case we'll fail the execution.

Cheers,

Simeon.

unknown

Hallo @Simmo ,

It is not only Misleading, there also is a Bug involved.

My Example was that i have a rule that is triggered by a comment in a JSM Project. Because of workflow reasons i want the Rule to be executed by the Person who commented, because there is other Things triggered by that. (Details in https://getsupport.atlassian.com/servicedesk/customer/portal/48/PCS-27466)

The Rule checks if the User is an Agent at the first Step after the Trigger, but since JSM Customers can comment too, in those cases the rule just fails, instead of checking if the User was an Agent.

So either you could check the Conditions of the Rule as Automation and only the Actions are executed as the User or the complete Rule switches to the Automation User if a Permission Problem comes up, as the Label suggests.

If you want to replace the "old" JSM Automation with this, this has to work.

Best Wishes
Michael

wwalser

Hi all,

The wording of the warning message is confusing and we will update it.

For the moment I believe we will go with the following — which I hope explains the reality of the situation better:

Due to security restrictions, there are certain users who cannot run “User who triggered the event” rules as the rule actor. This includes users created by Marketplace apps, and special admins. In these situations, the actor will be “Automation for Jira” instead.
If a rule is allowed to run as the ‘’User who triggered the event’' but the user does not have permission for certain actions then the rule execution will fail.

There are a few different facts which collude to prevent us from doing what I believe you want given your question:

First, we can not execute rules as a user regardless of that users permission levels. This is both a technical limitation and a policy limitation. The reason for this is that we don't want automation to be a vector by which bad actors could achieve permission escalation — perform some action which they should be prevented from performing.

It sounds like the old automation system may have allowed this? I'm not intimately familiar with its behavior in "run as" mode, but if this is the case, I can't imagine that it would have kept that feature for long. Eventually someone would abuse it and the team would have had to implement tighter security precautions.

Second, we can't check for permission limitations before a rule is executed. Because rules generate dynamic sets of issues on which to operate and indeed even operations to run, we can't know before execution what permissions will be needed for a rule.

Finally, we can not retry actions as a fallback when they fail for permission reasons. We avoid this because actions are sometimes multi-part and we don't want to erroneously duplicate work done.

Given these factors a fallback to a different user is not an option in most of the cases that people care about. Failure with an alert is the best option to locate and resolve permission limitation based failures. In every use case that we've seen thus far, this kind of failure was either desirable (because customers want their permission setups to be followed even by automated processes) or could be worked around by improving the permission setups or rule design.

All of this to say that "the user does not have permission for certain actions then the rule execution will fail". For the time being this is intentional and something which we do not intend to change.

Best,
Wes

unknown

@wwalser Thanks for your detailed answer. I understand that you can't undermine Permission Restrictions through rules, but right now i have the Problem that i have a rule that should be executed as the user who wrote a comment, but i can only check if the User has permission after the Trigger.

So the rule constantly throws errors because i have no chance to filter for the users i want the rule to execute. (See Screenshot)

Screenshot 2021-02-19 084844.jpg

Would it be possible to include a User Condition into the Trigger? I think Triggers with conditions would be very useful in other scenarios.

Thanks

Best Wishes
Michael

unknown

Also the Error Message is quiet misleading as well:

Screenshot 2021-02-19 085845.jpg

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

automation