Implementing Issue Security without bulk updating

[Alexander Allen]

I would like to implement Issue Security across a number of projects to allow an external partner to view issues that are relevant to them. Since the vast majority of tickets in each project do not apply to them and I would like to keep them private, I want to update only the few tickets that I intend to expose.

But from what I can tell, it is not possible to set a default value for the Security Level field that will apply to historical issues (Although, any newly created issue can be configured to have a default value for that field). When I apply an Issue Security scheme all historical issues in the project simply have the value for Security Level left blank and is therefore viewable by anyone with Browse Project permissions (which is required to view anything in a project at all).

This creates a problem because implementing Issue Security would then require me to bulk update the Security Level field in thousands of old issues and across a number of projects to keep those historical issuse concealed. Doing so would damage any reporting or dashboards that pull based on the "last updated" value of a ticket.

Is there anyway to apply Issue Level Security that silently updates issues in a project with a default Security Level value without recording an issue update?

[Ignacio Pulgar · Accepted solution]

There's an easy way to get exactly what you need:

1. Add all External Partner users to a group, ie named: external.
2. Ensure External Partners do not belong to any other groups or project roles that might grant them with any permissions in tge project.
3. Create a group picker custom field, ie named: Invited Group(s).
4. Add Invited Groups field to the screens where you would like it to be available.
5. Add Invited Group(s) field to the Browse Projects permission in the permission scheme. (Group custom field value)
6. [Bulk] edit the issues you would like to share with your External Partners by setting the 'external' group as the value of Invited Groups field.

After completing those steps, you'll be able to grant access to the issues you want without having to update the old ones.

Please, note that, on granting Browse Projects permission to the group value of a custom field, the *project name* of a so configured project would be listed to all users in your Jira instance. This does *not* grant access to any issues in the project, so it's completely safe to set the project that way.

[Matthias Gaiser _K15t_]

Nice way, @Ignacio Pulgar!

[Ignacio Pulgar]

Thanks, Matt!

[Ignacio Pulgar]

Oh, and of course you may add the Invited Group(s) field to any other desired permissions in a similar way.

[Andrei Bacanu]

This is gold, to be honest :)

Thanks Ignacio!

[Ignacio Pulgar]

You are welcome! 😃

[Matthias Gaiser _K15t_]

Hi @Alexander Allen,

I agree that updating issues via the UI would result in also updating the "last updated" field and would therefore break your reporting based on that field.

The one solution I could think of is modifying the data directly in the database, but if I look at the tags you provided, you're on Jira Cloud, correct?

An alternative approach to this problem would be synchronizing the issues you like to share to one (or multiple) separate project(s). You could then simply grant your external partner access to that project and don't worry about setting the issue security levels. If you're interested in that path, check out the issue sync solutions in the marketplace.

I'm part of the team behind Backbone Issue Sync. If you have any questions, please ask them either here or via support@k15t.com.

Cheers,
Matthias.

[Andrei Bacanu]

-