Having issues with setting security level in automation

[Jane Mitchell]

I've read and referenced ticket: 

https://community.atlassian.com/t5/Jira-questions/How-do-I-set-the-right-permissions-so-Automation-app-user-can-do/qaq-p/1371186

That said, I'm still having the same issues despite applying "BetterLife's" solve for adding the atlassian-addons-project-access to both of my security levels for my project.

The workflow I have:
I have an issue type that is very locked down and uses the security level that has very few permissions assigned to it - excludes Set Security Level. I have an internal version of that issue type which uses the security level that has full permissions including set security level. 

I have automations that take the issue from the locked down type -> the internal type when certain criteria is met. When those automations happen, the tickets are flow to transition and a user who shouldn't be able to see the internal ticket and its additional fields is seeing them until they refresh. To solve for that I tried to add a "Set Security Level" step to the automation BEFORE the issue type changed to the internal type.

My expectation was that the issue would no longer be visible by the user and THEN the automation would change the type and our internal people could see the ticket with all the added fields. 

What I experienced was that the automation failed at the Set Security Level citing "Actor does not have permission..." and then the automation would fail before the next step of changing the issue type to the internal type. 

The addons is part of both security levels. 

The addons is added to all permissions in the permission scheme. 

Here is the flow that is failing:

 

If I change the order of the automation to set security once the Issue Type is the internal type with all the permissions, then it works fine.

[Trudy Claspill]

Hello @Jane Mitchell 

Welcome to the Atlassian community.

When asking for help with an Automation Rule it will enable us to help you if you share screen images of your entire rule, details of each step, and the details of output in the rule execution Audit Log.

Who is the Actor for the rule?

[Jane Mitchell]

Got it - original ticket updated to include screenshots. 

The actor is Automation for Jira.

[Trudy Claspill]

Thank you for the additional information.

So you found a work around.

If you want to continue to debug the version that doesn't work, can you provide the following?

How exactly have you "locked down" the one issue type?

Can you share with us the security level configurations?

Can you share with us the Permissions you have granted to the add-ons role in the Permission Scheme used by the project?

[Jane Mitchell]

The workaround isn't actually valid as it only works when I'm in an internal ticket moving to the less secure ticket. I am not able to first set security and then set issue type to the more secure level and type. 

In the example screenshots above, for the workflow where I'm moving to less secure level, the workaround then exposes the internal ticket type to the external users while the automation finishes running the 2nd step to set the security level. That is not a functional solution for my purposes.

The only way to lock the one issue type is using the security level. Because you cannot assign a security level to a specific Issue Type, I have to rely upon the Automation to manage that for me. (Note: I've also tried transition Post Functions and they do not work)

Security Level "AiR-project-access" is set to only expose a single project within Jira for the external users. Members that are external are assigned to that level while internal users are assigned the default level. That issue security scheme is applied to the project.

Adds on role has access to every permission so the automations can run any of the steps in the project. 

[Trudy Claspill]

Hello @Jane Mitchell 

Thanks for the clarification.

I have attempted to recreate your scenario and I am not encountering the same problem. In my rule I was able to execute the action to set the issue to the more restrictive Issue Security Level and then execute the action to change the issue type.

The only things that should affect the execution of the rule is the Rule Actor, the actor's permissions, and the Actor's membership in Security levels. If you are using Workflow Properties that might also impact the rule.

I am experiencing some confusion with the way you have used specific terms. 

I'm hoping if we can clear up the terminology then I might figure out why the process is working for me but not for you.

So let's see if we can clear up my confusion on your terminology.

Security Level "AiR-project-access" is set to only expose a single project within Jira for the external users. Members that are external are assigned to that level while internal users are assigned the default level. That issue security scheme is applied to the project.

In the above paragraph, and using the images as reference, I'm a little confused by your terminology. The Security Levels are named Gallium and AiR.

The term "AiR-project-access" shows up in the Roles field on the People page for the project, so that seems to be the name of a Project Role rather than a Security Level.

It looks like you have two user groups: jira-air and jira-software-users-gallium. Do you assign your external users to be members of only the jira-air group, while your internal users are members of jira-software-users-gallium?

Next, can we clear up the terminology from this paragraph?

The workflow I have:
I have an issue type that is very locked down and uses the security level that has very few permissions assigned to it - excludes Set Security Level. I have an internal version of that issue type which uses the security level that has full permissions including set security level. 

You reference a "security level" that has very view permissions. But Permissions are not associated to Security Levels. Permissions can be granted to project roles, user groups, individual users, and so on, but not to Security Levels. Also the Permissions are applied to all issue types. An issue type does not have permission associated to it.

However, through workflow properties it is possible to apply more restrictions beyond what has specified in the Permission Scheme, and a Workflow can be associated to an Issue Type. Have you used Workflow Properties to apply more restrictions to one or more issue types?