Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

permission to create specific issue type

Im not sure how to accomplish this..

I want just one group to be able to create issues from a specific issue type.. can't find a documentation to do this..

9 answers

1 accepted

4 votes
Answer accepted

This isn't available. There are some workarounds, involving javascript or workflow tricks to prevent users actually committing an issue they shouldn't, and I've seen some hacks in code that do it, but it's not a standard function.

Hi if anyone stumbles on this conversation, I'm using a validator on the "Create Issue" Transition.

'Users in a field are/aren't in a project role'. Choose Field Reporter and select the roles you need.

Of course, this means you have a different workflow per issue type

Hi Amine, why would you need different workflow per issue type?

I used script runner build-in method isUserMemberOfRole for having few combinations of issueTypes and Roles.

Like Peter Weimer likes this
Tarun Sapra Community Leader Dec 03, 2013

Hi Amine, why would you need different workflow per issue type?

I used script runner build-in method isUserMemberOfRole for having few combinations of issueTypes and Roles.

Amine where do i find "field reporter" I could not find it in Validators list

Tarun Sapra Community Leader Jan 26, 2014

I have done it in a different way, I have used script runner plugin to a put a one line script in the validation section of the create transition.

you need to look for validator 'Users in a field are/aren't in a project role'. And then choose user in field : reporter

Not sure if this validator is in standard jira or a plugin one

Tarun Sapra Community Leader Jan 26, 2014

@Yasmine, in the script plugin, there is a built-in validation which says "Reporter is in a particular group"

@Amine: I could not find this validator ( didnn't you mean for a transition i add a validator?"

@Tarun: I actually checked this but there is no script runner for onDemand and I actually dont know why there are alot of plugins not available for onDemand

Tarun Sapra Community Leader Jan 26, 2014

@Yasmine- oh ok. actually script runner is one of the best plugins for JIRA not sure why it isn't avialble for ondemand.

Atlassian don't have the resources to support every single plugin their users *might* want to install. OnDemand is set up to be supportable, so they have to limit the range of plugins to ones they know they can support.

I completely understand their exclusion of the script runner though. It's a good, flexible, well supported plugin, which would usually be a good canididate to include in OnDemand. However, it's power is that it exposes most of the internals of Jira to the administrators and effectively allows them to code. Which, in the hands of an inexperienced developer/admin, is a recipe for generating vast numbers of support calls which all start "I tried to do clever thing X with the script runner and it went bang". So, despite being useful and well behaved, it can be a nightmare to support.

Tarun Sapra Community Leader Jan 26, 2014

@Nic, Yes I completely agree with the fact that you can do loads of cool internal things with script runner without the need of trying to write you own plugin, however i kind of disagree with "despite being useful and well behaved, it can be a nightmare to support", since the plugin is so damn useful thus it should be supported on the onDemand instance, yes there would be bulk of support tickets but with time naive admins/users would know the right way to handle it's power. Large number of support tickets shouldn't be a deterrent in supporting this useful plugin in the onDemand Environment.

Large numbers of support tickets generated by allowing people to make (potentially catastrophic) mistakes simply is not supportable.

I've worked with the script runner a lot. In most cases, it's great. But when you get a combination of the script-runner (or other clever plugins) and an inexperienced admin, you end up wasting a LOT of time working out and unpicking the mistakes. And in some cases, weeks carefully rebuilding messed up systems.

The vast majority of OnDemand users would be fine with this, but the handful that aren't would chew up a vast amount of support time. It's simply not worth it!

Like # people like this
Tarun Sapra Community Leader Jan 26, 2014

For me your stmt. "The vast majority of OnDemand users would be fine with this, but the handful that aren't would chew up a vast amount of support time" actually makes the plugin worth-while to be supported on the onDemand instance. Also, you have preview clause in some scripts and should also test it on the test environment first.

@Tarunso what do you use that you were able to use Script-runner?

No, it's completely the opposite.

Think of it this way, you go to a meeting with your boss and say "I'd like to allow our users to inflict massive damage on their system, with us having to pick up the pieces when they do? For free". No-one in their right mind would take that gamble.

Tarun Sapra Community Leader Jan 26, 2014

@Yasmine- Our jira is self-hosted so we were able to use the plugin.

Tarun Sapra Community Leader Jan 26, 2014

Well kind of agreee with you but not completely, there are only handful users that would do any hard to the system and even out of those handful users there would be very few users who would end up doing something catastrophic, I think it's a "calculated risk" keeping in mind the value provided to the majority of users who would be using the plugin.

You would also know the fact that there are some paid plugin being used whose functionality can be replicated by the script runner plugin which is free of cost thus it offers some monetary benefit as well for the end user with some basic scripting skills.

That's the point - the "handful of users that would do any harm" are going to make mistakes that chew up a disproportionate amount of support time. The calculated risk here is "massive big red expensive thing".

You really need to consider this from a support manager's point of view instead of the user. Try it - you'll find any sane support manager will laugh at you and then hold out their paw for you to triple their budget before they'll do it.

Your statement makes sense ONLY if Jira was free. When you charge for a platform, then support volume is part of the game. You just can't mark tickets that are important to an organizations "Won't Fix" and then disable their ability to improvise because support is overwhelmed by inexperience users. Remember you are in business to support your customers. You either have to provide the features they want/need (regulated by Atlassian/Jira developers) or allow them to experiment themselves. If you choose neither, then ( u know the REST !!!)

Er, have you read my last statement? Look at the support managers view. And remember that this decision *has* been "regulated by Atlassian/JIRA developers". And they've said "no"

Amine - I'm using JIRA 6.4.3. and I don't see the options you are describing. Adding a validator to the Create Issue transition in my workflow, only provides the option of select 'Permission Validator' then choose a global permission option. I don't see where to select which project roles I want this rule to pertain to. Did something change or am I looking in the wrong place?

@Tarun Sapra ,


how you restrict issuetype creation using custom script. I'm using getProjectRoles() and it is not working. can share how you implemented script for this?

I recently developed a plugin that might help you. I'm open for ideas to make it better, so just email me.

Working fine for us. Thanks!

Downloaded the plugin and find that it does not work. Maybe i am not setting it up correctly. Is there any documentation/help that i can use?

There is a manual on the website. Please read it and see if it works. Otherwise goto and describe your problem.


Your plugin works for the server. Is there one for the cloud version ?

No cloud version yet :( 

As Nick says, workarounds are available by using a Velocity processesed message custom field for view, and put the condition in the default value in the custom field by which the create button will be disabled.

Link to the old question forums

hmm.. is there a possibility to somehow restrict creating the issue for anybody via screens? The user who is allowed to create creates them throug REST interface...

Um, we just said you can't do it on screens without some code. REST will respect the permissions in Jira, but as this isn't something you can do in Jira, there won't be anything in REST (again, without coding)

looks like this doesn't work in 5.0 anymore. I cant find a "edit message" custom field. When I add a normal textfield with the script it just displays the script.

I know there's a lot of interface changes in 5, but I've not really worked with v5 seriously yet.

The "edit message" field though - that comes from the Jira Toolkit plugin (which is one of a handful of plugins that are so useful, I struggle to use Jira without them)

Thanks I found it. It doesn't save it when I enter something in "set default value". Am I missing something or is this probably a bug?

@Renjith : Hello, I've the same point and would like to visit the link in the old forum you've given, but I'm unable to find it :

Where could I find it in the new forum ?

Thanks in advance for your help

The forums were shut down, I'm not sure Renjith has re-posted the same answer anywhere.

Also, this is quite old and it relies on the "velocity processed message" fields from the Jira toolkit, which aren't there any more.

The principle is similar though - you can use a "message field" to tell the user that they cannot create this issue type and a mandatory field that isn't on screen to force validation to fail.

The workarounds discussed in that forum (if I remember correctly) are there in this feature request -

But I am afraid that it is so old that those scripts won't work anymore for the new JIRA interfaces (also considering that we have now pop-up dialogs for Creating issues).

@Niccan you just let me know where i can find "message field" and "mandatory field ", and if we put this mandatory field that is not on screen to force validation to fail , you mean by that , certain users won't abe able to see the option of create an issue for example or they will get a message and create will fail?

Message fields are in the Jira Toolit plugin. Make sure that's enabled in your Atlassian account and then the next time you add a custom field, you should see "message field" on the list of types.

Mandatory fields are set in "field configurations". They will not actually help you here though - you've reminded me that you want "certain users", which is not possible without some coding. A field is either mandatory or optional, the user trying to create the issue is not important.

Script Runner is not available on cloud.


The best solution I think is to create a separate project and add this issuetype. Then you can configure permission to create issue. This way is advised by Jira architectors. It is not a good idea to first show creation screen, let user fill everything, press Create and then get notified that he cannot create an issue. A better way is not to show any UI at all.

Is the ability to set permissions per issue type still not available for JIRA 6.2?
I would think that there should be some function on "Issue Types" to add permissions per type.

0 votes
Tarun Sapra Community Leader Mar 04, 2014

No it isn't in 6.2, script runner is the best option right now, see discussion below.

Maybe not so nice, but there is a way

1. Make unique Workflow for each Type

2. In each workflow set in validator on Creation transition a specific Permission (like Set Issue Security, Delete All Comments, Edit All Comments, Delete All Attachments or Time Tracking Permissions which we are not using)

3. Create permission schema where assign this specific Permission to proper Group of users

at the end Group has right to create issues of specific Type

See my comment later - validator will work, but it's a bad UX.

With Workflow Enhancer for Jira you can create a Universal Validator that checks [groups] user is in, evaluating to true or showing a custom error message to user.

Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you