How to set permission on issues creation by issue type

[Amir Katz (Outseer)]

I am migrating a project with its issues from one Jira server to another.

In the old project, we have several project-specific issue types (no problem there), but there are several issues of types Customer Request and Task, which are standard Jira issue types.

In order to migrate the old issues, I must add these two types into the new project's issue type scheme.

The side effect of this is that new issues can be later created with these types.

I need to block this option as we do not want any new issues of these types.

In related post that I searched the suggestion is to tweak the workflows.

However, I cannot change the workflows of these issue types (being standard Jira workflows), nor can I change the project's issue type scheme post-migration (I assume it will be rejected since there are issues with these types).

I also do not see how to it via a permission scheme, since it's action-oriented and there is no way to block Create Issue action based on action details.

Any idea?

[Joe Pitt · Accepted solution]

JIRA doesn't allow you to block an issue type. Since you won't be creating any more I would move them to a different project with only browse access before moving everything else. 

[Amir Katz (Outseer)]

@Joe Pitt Thanks, interesting idea. I will look into it.

[Amir Katz (Outseer)]

Still waiting for more answers, but in the meantime, the only idea I have now is to add a script listener on Create Issue event, and if a "bad" issue was created in this project, the listener will notify the project lead and/or admins and they will reprimand the reporter and then close/delete the issue.

Since all reporters are internal people, it's more an issue of education vs. prevention...

Amir

[Max Foerster - K15t]

Hi Amir,

do you use any workflow apps in your instance? Would it be a viable solution to validate the selected issue type in the Create transition and block the creation of unwanted issue types?

[Amir Katz (Outseer)]

Max,

Thanks, but as I said, those issue types use global workflows, so I cannot make any changes in the workflows.

[Max Foerster - K15t]

You could by using workflow apps from the marketplace. That's why I ask if you already use any in your instance. For example, using Jira Workflow Toolbox (we're developing it) you could achieve that by using the boolean validator on the Create transition and checking for the project and issue type like this with a conditional operator:

%{00018} = "Project Key" AND %{00014} = "Your issue type" ? false : true 

where %{00018} is the field code for project key and %{00014} is the field code for issue type.

You could even use "issuetype is IN". And that's just a possible solution using JWT. I'm pretty sure other tools will have similar possibilities.

So if you just answer my initial question maybe we can help you to figure out a way :)

[Amir Katz (Outseer)]

Hi Max,

We do use several add-ons, but JWT is not one of them. In any case, adding a global action on every issue create action (in all projects) seems like shooting a mouse with a cannon. And it will require buy-in from the corporate Jira gods, which it's not easy to get.

[Max Foerster - K15t]

I laughed because of your last sentence. And I know it's not the best way but it's a pretty straightforward validation that won't do much harm and solves your problem. I have other solutions in mind but that'd need more knowledge about your instance. In the end you have to pick your poison ;)

[Brant Schroeder]

This isn't available. There are some workarounds, involving workflow tricks like you stated to prevent users actually committing an issue they shouldn't but it's not a standard function within Jira.  You can also try a JavaScript hack but it might break in future updates - https://community.atlassian.com/t5/Jira-questions/Hide-select-lists-of-Project-and-Issue-Type-from-the-Create/qaq-p/241794

-https://community.atlassian.com/t5/Jira-questions/Hide-Issue-Type/qaq-p/216594

There was an issue on this that Atlassian closed as won't do which means they will not be providing that functionality in the future.