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; } } }

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.

Accepted answers

Trudy P Claspill

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.

All comments

Trudy P Claspill

Hello @Mathew Lederman

Mathew Lederman

@Trudy P 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:

Do you know if there is a list somewhere of functions the Automation for Jira account can perform despite workflow/project-level restrictions?
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 P 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.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud