Automatically assigning Security Levels to existing Issues

Question

Hi all,

I am currently using Jira Software 8.7.1 and Jira Service Desk 4.7.1. I want to assign to each of the existing Tickets(Issues) a Security Level. There are multiple Security Levels, around 50, and several thousands Issues.

Since there are so many, I would like to know if there is a faster, more automated way to do this. I know there is the Tool called "Bulk change" already built in, but I would still have to select each Issue manually, and I can apply the same Security Level for all of them(and that doesn't help with my problem). I was hoping for something that would "read" a certain custom field from the Issue, and assign to it the corresponding Security Level.

As an example, I have a custom field "group" that can take as value one of the user groups from user management. For each group, I have created an Issue Security Level that is assigned to that group. Is there a way to specify a rule that, for an issue with value "X" on "group" field should assign automatically as security level "X security level". And if it is possible to do this for the already existing issues as well.

Thank you

Andrew Laden · Accepted Answer

There are a couple of options, but not necessarily pretty ones.

The main issue is you need a way to map value X in the group field to Security level x. (I dont believe you can copy a text field into the security level field, though to be fair, I haven't actually tested that)

If you are using a scripting plugin (powerscript or scriptrunner) then you can do this fairly easily.

If not, you are probably going to end up in some if/then type pit, When you have 50 if/then style statements. You could do this with JSU for example using preconditions.

That said, there may be a better way to do this.

When setting the security Level, you can include as a value a "Group custom field value"

Ie, you pick a field that contains groups, and when you include this field in the security level, any groups in the field get access to the ticket.

So in reality, you may only need 1 security level defined, that include the group custom field that contains your groups.

This also give you more options, as you can have 2 groups fields. And then have logic that when group field A contain group1, then groupfield b should contain groups 1 and 2 for example. since you are just manipulating group fields, this should be easier.

Ed Letifov _TechTime - New Zealand_ · Accepted Answer

Andrei, please follow the advice that Andrew gave you on using a single Security Level with "group custom field value"

We went through exactly this exercise with a customer several years ago. The original plan was to have more Security Levels (around 900?) and we hit a limitation in Jira, where basically if it is more than 10 levels (if I remember correctly) everything just grinds to a halt.

I found these issues: https://jira.atlassian.com/browse/JRASERVER-38136 and https://jira.atlassian.com/browse/JRASERVER-44277

Even though these are old, and there is a mitigation, why go this route if there is no reason to?

For the customer in question we implemented a single security level, matching the value of a custom field that contains group names, looks like a select list/drop-down, behaves like Security Level (you will only see values that match groups you yourself are a member of), including in autocomplete in JQL (this was their main requirement - not to show members of one group what other groups exist in the system).

We did write a utility to bulk set the value of this new field based on the group picker value. The group picker field was later removed (since it is visible in JQL and shows all values)