Automation for Jira User Permissions

[Mathew Lederman]

Can somebody explain to me the permissions behind the native 'Automation for Jira' user? We have ~300 automations for a single project and Automation for Jira can run about half of them where our service account from DC, "Jira Service Management, Automation" can't. And for the other half, the scenario is flipped: our service account can run the automation and the native account can't.

I can't find any good explanation for why this is the case.

[Trudy Claspill · Accepted solution]

Hello @Mathew Lederman 

The Automation For Jira user is added by default to the role "atlassian-addons-project-access". That role is given all permissions in Permission Schemes (used by Company Managed projects) by default. If the Permission Scheme has been modified and that role removed from permissions, that can impact the ability of rules to be run with Automation for Jira as the actor.

If you change workflows to add Conditions or Validators that restrict who can execute the transitions, that can also affect the ability of the rule to execute successfully if it is trying to transition issues.

The role is not explicitly available to use within Team Managed projects. It implicitly has all permissions in Team Managed projects, but again can be affected if you create restrictive workflow rules.

With regard to your service account you would need to also look at the permissions it is allocated in the Company Managed project Permission Schemes. Since the account is a "real user" you would also need to assign it to appropriate Roles in the Team Managed projects for it to be able to run rules against those projects.

[Mathew Lederman]

@Trudy Claspill appreciate the information. 

We're actually migrating from DC to Cloud, so it's not quite as straight-forward as it may seem. All of our automations/functions in DC were based on the service account, so it's odd that the account can't perform some transitions in Cloud.

Looking  through the permissions page in the project, the service account is a project admin with access to all permissions and the  atlassian-addons-project-access also has access to all of the permissions. And yet, they don't share permissions.

One simple example from today: In Cloud Automation for Jira can edit fields not part of the edit screen. Our service account cannot (though it could in DC). 

To your point though, we have many transitions restricted to project administrators, and since the Automation for Jira account is not an administrator, it won't be able to perform those functions.

Two things that would REALLY help my team:

1. Do you know if there is a list somewhere of functions the Automation for Jira account can perform despite workflow/project-level restrictions?
2. Do you know if it's possible to add Automation for Jira as an administrator? This would likely resolve a lot of our issues.

[Trudy Claspill]

In Cloud Automation for Jira can edit fields not part of the edit screen. Our service account cannot (though it could in DC).

This warrants more detailed investigation. If you want to pursue that I recommend you open a separate Question for that specific topic.

we have many transitions restricted to project administrators, and since the Automation for Jira account is not an administrator, it won't be able to perform those functions.

Did you set the restrictions to the Administrator role?

1. I am not aware of any document that list functions the Automation for Jira account can perform despite workflow/project-level restrictions?. To the best of my knowledge if you have set up workflow or project level restrictions that prevent the "atlassian-addons-project-access" role from doing something by not granting the capability to that role, then Automation for Jira won't be able to do it.

2. According to this document there is an email address that represents the A4J user and you can use that to add the user to Project Roles.

https://confluence.atlassian.com/jirakb/automation-rule-failing-with-the-error-you-are-currently-not-a-member-of-the-project-role-service-desk-team-commentlevel-1223819947.html

[Mathew Lederman]

This warrants more detailed investigation. If you want to pursue that I recommend you open a separate Question for that specific topic.

Just more unexpected and undocumented changes from DC to Cloud. I believe I have a good enough understanding of the differences now for this pieces that a separate conversation isn't necessary.

Did you set the restrictions to the Administrator role?

We did, yes.

2. According to this document there is an email address that represents the A4J user and you can use that to add the user to Project Roles.

This is wonderful! Though it begs the question as to why this roundabout process is necessary, I'll take what I can get.

To the best of my knowledge if you have set up workflow or project level restrictions that prevent the "atlassian-addons-project-access" role from doing something by not granting the capability to that role, then Automation for Jira won't be able to do it.

Apologies, I don't think I was very clear on this one. There are project and global restrictions that A4J CAN bypass. For example, if a custom field, List of Approvers, is not on the edit screen a regular user cannot edit the field through issue view, automation or anything else to my knowledge. However, Automation for Jira can edit the field through project automation.

[Trudy Claspill]

Apologies, I don't think I was very clear on this one. There are project and global restrictions that A4J CAN bypass. For example, if a custom field, List of Approvers, is not on the edit screen a regular user cannot edit the field through issue view, automation or anything else to my knowledge. However, Automation for Jira can edit the field through project automation.

This is another that I think warrants deeper investigation through a separate Question. There are multiple questions I would ask and evidence I would request to explore a specific example of this occurring.

I have seen Automations report that they could not edit a field when the field was not included in the Edit Issue screen and the rule was running under the Automation for Jira identity. So I would want to dig into the details of the scenario where you see that A4J is able to edit such a field.

[Mathew Lederman]

This automation works when the Actor is A4J but fails when the Actor is a service account with that is actually a site-admin, full system admin access, full project admin, JSM license and every permission available on the project. The field "RQM - List of Approvers Level 2" is not on the project's edit screen and should not be on the project's edit screen as users should not be able to define approvers.

[Trudy Claspill]

You raised a key points when you said "JSM license" and showed that it is an Approvers field that is being edited.

I am not as well versed in the unique functionality of JSM and Jira Software, so getting more eyes on the question would be valuable.

If you want to dig into this deeper, please start a new Question to ensure the best visibility of your question to the wider community. You might also want to consider posting it in the JSM Questions forum instead of the general Jira Questions forum.

When asking about the unexpected results of a rule, also include the details of the Audit Log output for the execution of the rule. And mentioning that the rule is operating against a JSM project is important.

Since this concerns modifying an Approvers field that could be another factor.

Since this has to do with what happens depending on the actor of the rule, providing information about the permissions, licenses and assigned project Roles would be valuable information.

You said the field is not on the Edit screen. Providing a screen image of that screen would be useful evidence.