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.

[Trudy 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 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.

[Bill Sheboy]

Hi @Marina Maznikova 

Looking at the rule you show, I recommend first adding the Re-fetch Issue action after the Issue Created trigger.  That trigger can fire so quickly that all data is not present yet, leading to unexpected behavior / errors.  Adding the Re-fetch Issue will slow down the rule a bit and reload the data before proceeding.

Next, I agree with Trudy's suggestion to use the default actor, "Automation for Jira", as it has unique permission range to help rules work across projects / configurations.  If you are observing symptoms in other rules as a result of using that actor, I recommend working through each rule with such symptoms to resolve them, perhaps with your Jira Site Admin, the community, or Atlassian Support to help.

For example, you note "the user who created the issue gets unwanted e-mails."  That suggests the user is the Reporter, Watcher, or Assignee of the issue, and their notification preferences send them emails.  That is the correct, default behavior.  If you want to change that, individual users could update their notification preferences, or the rule could be altered, such as changing the Reporter or Watchers.

Kind regards,
Bill

[Marina Maznikova]

Hi, it seems that you didn't understand me. I want that the reporter remains reporter and that he gets notifications when changes of the issue happen. But not when changes triggered by his actions happen! And no, I can't disable the notifications triggered by actions of the automation user because the reporter has to be notified for automatic changes triggered by other users. So, basically, the automatic changes are changes "triggered/done" by the user triggering the event, so they are to be interpreted (and also displayed in the history) as his actions. 

[Bill Sheboy]

Hi, Marina.  I did understand your concern, and wondered if it was for a limited number of users or for all users in the site impacted by notifications from rule actions.  (For a limited number of users, individuals changing their preferences can help.)

Others have had this same concern for quite a while, and here is an open suggestion to allow better options to suppress notifications caused by automation rule actions.  You may watch / vote for it to see progress: https://jira.atlassian.com/browse/AUTO-602

[Marina Maznikova]

All users have the problem. And as I said, suppressing the notifications for the automated actions is not an option/solution for me. Users should get notifications when they have not triggered the automatic action themselves. So, basically, the actor for the automatic action needs to be the user who triggered the action. Then the history is correct (= as wished) and the notifications are fine. Until now, also the rules were working, so my problem is that now they no longer work.

[Trudy Claspill]

Hello @Marina Maznikova 

In your original post you said:

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. 

Related to that I have a few questions:

1. What query exactly did you execute? Did you execute the full query shown in the error message?

2. In the instance where the rule was triggered and failed, was the rule triggered by action you took, or be actions taken by another user?

3. If it was triggered by actions taken by another user, is that user successful in executing the full query shown in the error message?

4. Does the rule work for any user or does it fail for every user?

Another thing to look at:

1. Have the Browse Projects permissions in the specified projects been modified for the users for whom the rule fails? Is that permission in the specified projects allocated to user groups or project roles? For the users for whom the rule fails, have their groups memberships or project role allocations been changed

You say that the rule used to work fine and you have not made any changes. Are you sure that while if was working fine it was being triggered by users that had access to only one and not all of the projects in scope? If you think it was previously working for users that did not have Browse access to all projects in scope, then you might want to open a support case directly with Atlassian to see if something has changed in how Automation Rules work. I have never looked that closely at a situation like this, where the actor of the rule might not have access to all the projects in a Multiple Project scoped rule.

Given the current behaviour of the rule, and the requirements that the notifications be sent by the actions of the rule based on who is triggering the rule, it appears you have two choices.

1. Allocate at least Browse Projects permissions to all the in-scope projects to all the users that might trigger the rule in any of the in-scope projects.

2. Create separate rules based on projects that have the same set of permissions for the same people.

[Marina Maznikova]

1. Yes, the rule written in the error

2. By another user

3. As said in the other comments, the user has access only to one of the projects. So he shouldn't be able to execute the query. That is why I understand why the rule fails. But I don't understand why the user has to have access to all projects to which the rule is applied. This makes absolutely no sense.

I am not sure that the behavior has changed... unfortunately... I have a lot of rules applied to multiple projects and never had issues with that before. But checking exactly what has been triggered by whom until I find an example is too much effort. 

Yes, it seems that my only option is to multiply the rules. :( That is really said. Giving all users access is not an option. Especially when it comes to HR projects and other highly sensitive information.

[Trudy Claspill]

I can't address why the rule may have worked in the past when triggered by users who, at the time, didn't have access to all the projects in the rule scope. To dig into that would require having evidence that the rule worked at that time, who triggered the rule, evidence of the Projects that were in scope at the time, and evidence about the rule Actor's access (or lack of) to each of the projects in scope.

As to why the actor must have access to all the projects in scope that has to do with the way the rule evaluates conditions. 

For the condition "If parent exists" it doesn't matter what project the parent issue is in. The rule only needs to check the trigger issue's Parent field and confirm it is not empty.

key={{issue.key}} and Parent is not empty.

For the second condition the rule needs to look at the data in the parent issue itself. For that condition it is also must confirm that the Parent issue is within the rule's project scope. Parent issue may existing in a separate project from the child issue (in some cases). Therefore it applies the "project in (X,Y,Z)" criteria as part of its evaluation of the parent issue. 

If the actor of the rule does not have permission to view the issues in the parent issue's project, then they would not manually be able to evaluate the condition. Therefore the rule, acting under that user's identity, also would not be able to evaluate the condition. The rule cannot access data that the rule Actor does not have permission to access.

Perhaps the architecture of automation rules could have been developed to compensate for this case by determining if the rule Actor has access to the specific project in which the parent issue exists. But that is not how the feature was developed.

[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.