Automation failed. Error: Actor does not have permission to view one or more issues, or the issue wa

[Mariam Slade]

I had automation working to automatically transition the status when someone comments. Now it has stopped working. Now it has stopped working. I am not the only person working on the project so I don't know what has changed. Whenever a customer comments it fails and the audit log says: "Actor does not have permission to view one or more issues, or the issue was deleted (please check permissions and issue security levels)"

As far as I can see customers have permission to edit their own issues. I don't have an issue security scheme, is this required?

Any suggestions on how I can get this working again?

[Hector Meurice]

Solved: How do I set the right permissions so Automation a... (atlassian.com)

Adding the role atlassian-addons-project-access into the security levels has solved a similar problem for me.

[Asparuh Georgiev]

Thanks Hector, that actually solved my issue as well :) 

Summary: Automation Rule involving "Actor" stops working when issue security is applied to a task.

[Simo Rajantaus]

Thanks, had the same problem, needed to add atlassian-addons-project-access to issue security.

[Blake]

I am seeing that adding this access has fixed your issues. But I am confused; this is in fact not a true fix of the original problem..

OP says the problem is that suddenly automation has stopped working, with zero changes made. So, why would adding an "access" into roles fix this, if it worked for X amount of time without this at first? This proves that at one point, this "access" was not necessary.

[Helge Nymoen]

Thank you Hector, this was really helpful 👍

[Scott Fannen]

Hi there,

I got the error:

• the issue didn't match the specified JQL (most likely)
• the chosen rule actor doesn't have permissions (or issue security level permissions) to view the issue
• the issue was deleted or wasn't indexed by Jira yet (in rare circumstances)

(Not actually an error - it just said "No actions performed")

Despite having all the access correctly done and despite the automation working earlier.

My automation was using IF statements to work on JQL checking cascading fields (since normal automation isn't great at cascading fields).  Effectively "if this option is chosen, assign it to this person". The JQL worked as expected.

To resolve it, I did two things (since I was in a panic to get it working):

• I split my automation into 4 separate automations (this worked even though they all worked "on creation"
• I changed my statements to IF/ELSE blocks (still checking JQL in them).

This worked - just posting it in case it helps someone else.

Scott

[Dana Gould]

This is not an answer but I am having a similar problem . 
I had several project automations running that have suddenly stopped working with. Whenever they are triggered, the audit log provides the same error:

"Actor does not have permission to view one or more issues, or the issue was deleted (please check permissions and issue security levels)."

These automations were running previously and nothing has changed in permissions scheme or security schemes. I've gone in and tried to add additional permissions to the admin user running the automations to no luck.

Is this a new feature that we now need to update our features around or is perhaps Automation currently down?

[Kyle Ouellette]

+1 to having a similar issue.

I have an automation rule that executes as the user who triggered the event for transitioning an issue if a comment isn't from a customer, isn't an internal note, and the issue isn't already transitioned. The rule works fine when the comment is from an agent, however, a comment left by a customer triggers the automation but it fails with the same error "Actor does not have permission to view one or more issues, or the issue was deleted (please check permissions and issue security levels)".

I'm at a loss why this is occurring because I would expect the "not a customer" condition to catch this without a problem. My best guess is there's an issue with the permission scheme which is failing because the customer doesn't have permission for the automation rule to check the fields and status that may be defined. I haven't modified the permissions at all from their defaults and I'm not too eager to mess around with them either.

Hopefully, someone from the Atlassian team can clear this up for us and provide guidance on how to proceed.

[Dana Gould]

Kyle,

Without knowing your rule, I can't speak to a solution in your specific use case.

For our issue, we found the following solutions:

• Replaced JQL with other alternatives (e.g. Issue Field Condition is usually our go to)
• Not knowing the full specifics, I am going to guess you may have hit the same wall I did and are trying to use the "Domain of Reporter" field, which was previously recommended by Atlassian as a workaround for currently missing and much needed functionality. While we still await our much needed security functionality, Atlassian has removed support of the "Domain of Reporter" field for security purposes. There is a way to reproduce the original's automation's functionality using the Advance Compare condition. (When using this solution for new customers highly recommended to re-fetch the data to ensure that the system has time to verify their email address.)

Hope this helps!

[Kyle Ouellette]

Hi Dana,

Thanks for taking the time to provide these suggestions! Unfortunately, these don't seem to apply to the rule I'm having issues with.

I'm not sure how closely related this may be to the rule you had, but this is what mine looks like. Also note the automation is configured to set the actor to the person who triggered the automation because the transition also assigns the agent to the ticket so using the automation actor doesn't seem viable for us:

1. Issue commented - Comment is the main action
2. User condition - User who triggered is not a customer
3. Issue field condition - Status equals "Waiting for Support"
4. Advanced compare condition - {{comment.internal}} equals false
5. Transition to "In Progress"

If anything immediately jumps out as an issue that you already ran into, I'd greatly appreciate whatever knowledge you've already learned :) If not, no worries, and I appreciate the help!

[Hector Meurice]

I had similar problem, and solved including the role "atlassian-addons-project-access" into the security levels. 

Solved: How do I set the right permissions so Automation a... (atlassian.com)

[Jawann Swislow]

@Kyle Ouellette

Did you even figure this out? I'm running into the same issue. Seems like a bug with the user condition resolution.

[Kyle Ouellette]

@Jawann Swislow

I did figure this out but unfortunately don't have full recollection of what exactly I did. I believe the following was the cause and the fix and may be worth giving it a shot if it applies to your configuration.

IIRC, the issue was our workflow was configured to assign the user when transitioned and because of this, I was setting the actor for the automation as "User who triggered the event" that way when the automation transitioned the issue, the workflow would know who the user was and could set it accordingly.

Looking at how I have it set up now, it seems that the resolution was to remove the user set from the workflow, set the actor to "Automation for Jira", and add a manual assign action and set that to the user who triggered the event.

I'm sure there are likely other ways to also work around this by fine-tuning the permissions but this seemed like the easiest and cleanest solution IMO.

~ Kyle

[Andy Hurley]

I have run into a similar situation, I have a rule that runs on all projects and checks to see if someone is mentioned in a comment. If so it sends a message to the commenter - a kind of OOO service. The actor is the one being mentioned as that seems to make most sense in this case.

The problem is that some projects/issues are not visible to everyone and so the automation fails to check the contents of the comment. Which is fair enough but I can't find a way to check for permission before trying to check for a match.

I guess I could make a global administrator the actor but that would seem like a security risk.

[Lovable Cow]

Automation for JIRA allows administrators (both global and project) to create powerful automation rules for projects.