Rule actor not found in permissions dialog

[brian_mesh]

Hi, we're running a next gen board and I've created several rules to enable various automations.  When I first tried to get this working, I was hitting errors where the rules didn't have permission to do that actions I specified. (the actor, as listed on the rules page, is "Automation for Jira").   I went to add that actor to either the project 'members list' or to the transition rules that were currently blocked... however I couldn't find any actor in either permissions location that was remotely similar to "Automation for Jira" (or as another community post suggested, "atlassian..." ). 

The result was that I had to basically make all board operations open to public to allow for the rules to be able to fire.  I could have tried changing the rule actor to myself, but didn't want everything to reflect myself as the actor.  

Anyone know how to allow next-gen board rules to transition issues between states without having to remove all permissions checks all together?

[Earl McCutcheon]

Hello @brian_mesh , 

Thanks for reaching out and the Previously named "Next-gen" projects, recently renamed to "Team managed", have the add-on access enabled by default so the rule should be able to be executed by the "Automation for Jira" role actor directly without issue, and the permission cannot be changed to remove the role actor.  So My suspicion is that something in one of the custom rules is triggering a conflict.

However, the Previously named "Classic" Recently renamed "Company managed" projects can run into an issue if the atlassian-addons-project-access role does have the appropriate Issues permission for the project to execute the actions in the rule where the permissions for this project type can be modified to remove the abilities of the app as the atlassian-addons-project-access role should be added to every permissions level for full functionality in this case. 

There is a really good discussion about this in the following thread which is most likely the other thread that you mentioned looking at already, and placing it here for reference incase anyone else runs into a similar issue and finds this thread:

• https://community.atlassian.com/t5/Jira-Software-questions/How-do-I-set-the-right-permissions-so-Automation-app-user-can-do/qaq-p/1371186

Are you by chance executing a global rule that is crossing over the Team managed project with a company-managed project, such as a rule to transition a linked issue, where the linked issue is contained in a Company managed project?

But overall I believe the best approach to troubleshoot this would be to locate the rule triggering the error from the audit log and send me a screenshot of the rule settings so I can see if I can identify the blocker for you and recreate the error.  A screenshot of the audit log page would also be really helpful.

Regards,
Earl

[brian_mesh]

Thanks Earl.

Yep, that was the discussion I was referring to but didn't have luck with.   To the global question, I think as I show below, this is not a global rule... nor does the content of the rule try to cross projects at all.

For context, we missed having a resolution field in 'Team Managed' Boards.  So we created one other 'Done' column to be 'Rejected' and a new "Resolved As" dropdown field.  When you change the "Resolved As' field, depending on the choice made, it automatically transitions the issue from whatever state it's in to 'Done' or 'Rejected" makes sense based on the 'Resolved As' field.  This rule works just fine if my work flow has no limitations on who can do what (which by the way is any state can move to any state).   As soon as I add a rule restricting the move 'any' -> 'rejected'  to be only for 'administrators' or 'members' of the project, then I start getting rule errors and the transition doesn't happen.

There's two audit logs below - the first is more recent and gives something that seems misleading about 'smart values', but the second was what I got when I first tried this a week ago and got a clear message about 'No transitions found for user. Ensure that the rule actor has permissions..."

Thanks!

Brian

--------
Here's where you can see the rule (the one with the red flag) is not a global rule:


-----------
Here's some of the rule details (at least all of it that executed on for the instance that I just triggered the issue off of:


---------
And here's 1 of 2 audit logs


---
A log from a different instance:

[Earl McCutcheon]

Hello @brian_mesh ,

Thank you for all the details, and I was able to make a slightly more simplified duplicate of the automation rule you have set up, simply with fewer transitions and the rule itself is working fine for me while testing this in both Private and Public configurations,  so it is looking like something else in the workflow (Transitions or rules) is triggering the error, not the settings in the Automation rule.

For reference on the differances I set up the rule like this:

In testing this out I was able to duplicate the error message "Destination status could not be resolved...." by restricting the workflow transitions, and rules like the following:

Noting that there are two failure points in the screenshot above

1. first, the issue has to be in the "In Progress" status to be able to be transitioned to the Rejected status, so if the issue is transitioned to Done then the "Resolved as" field is set to "rejected" the issue cannot transition as the workflow transition does not exist from "done" to "Rejected".
2. Secondly, the Transition from any status to Done has a rule where only the assignee can use this transition (so restricted to a specific user) and in testing, i left the issue unassigned

I can see in the error you listed that the issue was in the status "Backlog", Can you check out the workflow configurations and verify that there is a transition from Backlog to the desired resolution status, as well as check for any rules on the transition that would restrict to a specific user that could be blocking the automated transition action?

Regards,
Earl