You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
i have an Automation Rule in one of our Jira Projects, that is executed as the triggering User.
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:
Thanks for sharing, @[deleted]
This is helpful!
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.
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.
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.
@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)
Would it be possible to include a User Condition into the Trigger? I think Triggers with conditions would be very useful in other scenarios.