Automation error "To discard the user notification either admin permissions are required"

[Sanjay Samani]

I have an old Automation that has been working fine for a long time. It has been months since the last change to the automation. 

The error message is "To discard the user notification either admin or project admin permissions are required."

The edits to the issue are working correctly, but I am not getting notified of a failure every time the automation runs. 

The automation copies the values of some fields from the Parent issue on creation. The Products and Project Owner fields are custom fields. All the fields exist in the screen configuration / issue configuration for both the child issue types (Task, Bug) and Parent (Epic). The actual copying of the field values is working fine as before. It is just producing the error message at the end.

I actually have a couple of automations that started failing with this error on 23rd January 2025, which makes me suspect it was a product change in Jira that I need to account for, but unclear what I need to do.

[Saurabh Kapoor · Accepted solution]

Hello Sanjay,

Thank you for reaching out to the Atlassian support team. I understand that you're experiencing an issue with your automation rules, which have started failing with the error message: "To discard the user notification either admin or project admin permissions are required." This can be frustrating, especially since the automations were previously working fine.

I did further checks and found that when you add an edit issue action in the automation rule, the following check box is checked by default-

This option is turned off in your rule. So it looks like that is why these errors are occurring.

Solution: Enable the send emails option in your edit issues actions and that should fix the issue for you.

Here is what I learned by compiling all the incidents that happened in the past-

• The option that I shared earlier- 
  This rule should send emails. Rule actor must be an admin or project admin. __ is enabled by default in the Automation rules.
• Rule executions should have failed in the scenario when the rule actor didn't have admin privileges, whereas they were successful as a result of a bug.
• The Automation engineering team unintentionally fixed the bug by rolling out a feature,  but it started causing rule failures, leading to an internal incident.
• The team is now continuing the rollout of the feature that has fixed the bug, which caused all the misconfigured rules(where the checkbox was not ticked) to start failing.
• Customers should fix the configuration of these rules(where the checkbox is unchecked, the actor must be an admin) in order for them to start working again.

In short, Your rule was working earlier as a result of a bug, which is now fixed.

I hope that helps and apologise for the inconvenience. I can understand that it caused trouble on your end.

–
Regards,
Saurabh Kapoor
Cloud Support Engineer, JIRA
Business Hours: Mon. to Fri. 09:00 - 17:00 CET (UTC +01:00)

[Sanjay Samani · Accepted solution]

I reported this to support and got the following answer (my summary, their answer was a lot longer):

My automations:

- Had the Actor set as "User who triggered the event"

- In the Edit Issue action, under More Options, we had unchecked "This rule should send emails. Rule actor must be an admin or project admin"

We had both of these set these way so that the automations were not sending out spam notifications. We set the Actor as "User who triggered the event" as we found that reporters are often the only watchers of issues, and they were the ones triggering the automations, so setting it this way minimised notifications to themselves.

Prior to 23rd January, that these automations were running successfully. Atlassian support have told me this was a bug and they should have been failing because most users are not admins or project admins. So suppressing sending emails should have failed as the Rule Actor was not an admin or project admin.

They have fixed the bug (slightly unplanned as part of a feature update) so these automations are now failing correctly. 

The solution to achieve what we want to achieve (changes without notifications):

- Set the Actor to "Automation for Jira" 

- Uncheck the "This rule should send emails" in the Edit Issue action

I have changes some of my automations and am now waiting for them to trigger and see what happens before going through all of my automations.

[Sanjay Samani]

Ah, the support team member posted their explanation below as I was typing this. Thanks Saurabh for your help and taking the time to post here as well.

[Saurabh Kapoor]

If my answer was helpful you can mark it as solution, if not you can ask for more help :) @Sanjay Samani 

[Bill Sheboy]

Hi @Sanjay Samani 

Your rule is using the Issue Created trigger, and that has a known problem where the trigger can fire so quickly some data may not yet be present when the rule starts.  This symptom can lead to unexpected rule behavior and weird permissions errors.  In engineering terms, this is called a racetrack error: multiple things happen close together in time and it is unpredictable which will "win".  These symptoms do not always happen, which is why you did not initially see it.

The fix for this is to always add the Re-fetch Issue action immediately after the Issue Created trigger.  This will slow down the rule a bit, reloading the data before the other steps proceed.

Kind regards,
Bill

[Sanjay Samani]

Thanks for the suggestion. Will let you know if that works.

[Sanjay Samani]

So far, I've had two different Automations trigger after I made this change, and both failed again with the same error. I think I'm going to raise with Atlassian support. Thank you for your suggestion and help.

[Jack Brickey]

@Sanjay Samani , please keep us posted.

[Sanjay Samani]

I've added a top level comment for visibility with the answer from support. Essentially they should have always failed, and it is a bug that they were succeeding. They've fixed the bug and explained how to resolve the error.

[Jess]

Hey @Sanjay Samani I've also been dealing with this issue for a week or so. Everything was working fine, and then my automation started failing, just like yours! I'm glad you posted this in the community. I've had no luck so far with my own searches to find why this is happening. 

I'll be following along to see if we can all get this resolved. :) 

[Sanjay Samani]

Jill, I've added a top level comment for visibility with the answer from support. Essentially they should have always failed, and it is a bug that they were succeeding. They've fixed the bug and explained how to resolve the error. 

I'm testing with a few of my automations. Would be interested to see if it resolves things for you also.

[Jack Brickey]

Hi @Sanjay Samani , that is a very odd error. Ultimately I think you're going to need to report this to Atlassian support as it may be a bug or at least an obscurity. However, it would be interesting to play around with your rule a bit and remove all of the edits except one. Retest the rule and if there is no error add one more field to your edit at a time until you find the culprit if it even reproduces. In thinking more on that you might want to copy the rule and test the copy. This would preserve the error condition so that Atlassian could log in and have a look. it may be that if you completely rebuild the rule, it goes away, but unsure.