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 rule started failing because of project check

Marina Maznikova

This issue is not for work management but for Jira software/automation. I am sorry for the wrong community.

I have a very simple rule copying the epic's fix version to the tasks created in the epic. It is used in two of my projects. The rule has been active for months now and never caused any issues. The last time when it run successfully was on Oct 22.

Then, in Oct 24 it started failing due to the project restriction. I copied the query that is failing and executed it, it worked just fine. I have no idea what the problem with the rule could be. I haven't changed the rule for months now. But I already had a couple of failures and it would be great, if somebody could help me make the rule work again.

Accepted answers

All comments

Tuncay Senturk _Snapbytes_

Hi @Marina Maznikova

Welcome to the Community!

The error message in your screenshot indicates that the JQL query is failing because the project with ID '10028' does not exist. It might no longer be valid or accessible in your instance of Jira. Check your project access or if the project was deleted. If the automation is run by an automation user, ensure the user running the automation has access. That would be my two cents.

Marina Maznikova

I have already checked all this. Both project exist (and are selected in the rule details, I don't use the IDs nowhere). The user has the required rights. And in general, nothing has been changed in the Jira/project configuration in the last days/months.

Trudy P Claspill

Hello @Marina Maznikova

Welcome to the Atlassian community.

Who is the rule Actor on the Rule Details page? That is the user that must have access to the project.

What is the Type of each project that is within the scope of the rule? Get the project Type information from the View All Projects page under the Projects menu.

Marina Maznikova

Thank you! I found the reason for the problem. But I have no idea how to solve it.

The projects are company-managed. The actor is the user who triggered the event. The user is administrator in one of the projects for which the rule is configured and where the event has been triggered. But he has no access to the other project. This is causing the problem that I have in the last days.

I have a lot of "general" rules applied to all/many projects (like copy fix version, close subtasks, etc.), and no user has access to all projects, except me and the other Jira admins. Until now, I didn't have any problems with that. The user does actions in his project and the automatic changes also have to happen in his project. Why should it matter that the rule is applied to other projects as well? Well, now it matters. Should I then have plenty of duplicated rules? Changing the actor would be an alternative, but not really a better one (because of the user impact.. I had this at the beginning but it was terrible for the users and I had to change it). Are there other options?

Trudy P Claspill

The actor "Automation for Jira" should have access to all the projects, unless you removed it's Role from project permissions. Is there a reason you can't use that as the rule actor? What is the undesirable user impact you mentioned?

Marina Maznikova

It has the access rights but as I said, using it as actor causes other issues. For example, after an issue has been created, multiple things are done automatically and the user who created the issue gets unwanted e-mails. Same when somebody transitions an issue or does something else. Also, when new issues are created automatically (normally by a rule triggering another rule because in some projects there are more than 50 issues created automatically when e.g. a new release gets created), the reporter is the automation user which is an absolute no go. And so on.... Some of the problems can be handled with various other configuration changes but some cannot, and anyway this is too much overhead.

The rule worked the way it is configured for more than half an year. It is so weird that it is broken now.

Welcome!

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

Quick Links

Find more posts tagged with

automation

jira-automation