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 rules : Creator vs Actor

Kris Dewachter

Hi,

As a Jira Administrator, I only have 'Administer Projects' permission on all projects. I don't have 'browse' permissions on any of the projects.

I want to create an automation rule that creates a new Service Desk ticket when a certain condition is met. As 'Actor' of the rule, i set the 'SupportBot' user, who has full access to all projects.

In my automation rule, when i want to set a new 'Action' 'Create Service Management' request', I can not select any value for the fields 'Service Management' or 'Request Type'. There is an error message "No valid fields could be retrieved for this Service Management and request type. Do they still exist and does the rule actor have access?"

In this case, the rule actor has access to the Service Management project. When I give my "Jira Administrator" user full access to the Service Management project, I can create the new action without issues.

Has anyone else seen this behaviour before or can explain what is happening?

Best regards,

Kris

Accepted answers

Mark Segall

Hi @Kris Dewachter and welcome to the community! This is by design. Although the actor will have rights to execute the automation rule, creation of the rule is using your rights as "author" of the rule. Thus, you have two options:

Temporarily grant yourself rights to the project to create/publish the rule
Use a smart value to establish the request type

I would recommend option 1 because option 2 would add complexity that may be overkill.

All comments

Mark Segall

Temporarily grant yourself rights to the project to create/publish the rule
Use a smart value to establish the request type

I would recommend option 1 because option 2 would add complexity that may be overkill.

ACA IT-Solutions NV

Hi @Mark Segall ,

Thank you for your reply.

Solution 1 seems like a workable solution, but there are some moral concerns. Giving yourself access to Jira tickets you are not allowed to see might worry some people ...

Not having browsing permissions makes life as an administrator very difficult. Do you have any suggestions on what would be a better setup? I was thinking of automatically setting 'issue security' on all tickets in sensitive projects, so that you can have browsing permissions, but actually don't see any tickets.

Best regards,

Kris

Mark Segall

Issue security seems like a complex route

Since you're not comfortable with granting yourself temporary access to the project, here's a quick example of how I've used a smart value to populate request type on projects in the past. It was for a different use case, but the end result is the same.

The key is rather than the action "Create a new request" you use "Create new issue" then set the request type after the fact. The reason for this approach is that the "Edit request type" action supports a smart value. Now to set that, I took the approach of grabbing a simple text field like Summary and replacing that value with the request type name. Here's the text for copy/paste purposes:

{{issue.summary.replace(issue.summary,"<requestType>")}}

I'm not sure if this is the most elegant approach, but it has worked for my needs.

Welcome!

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

Quick Links

Find more posts tagged with

server

jira

jira-service-desk

jira-server

automation