permission to create specific issue type

Tobias Hofer February 2, 2012

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

5 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 2, 2012

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.

6 votes
Amine Teniou July 11, 2013

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

tsapra December 3, 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.

Like Peter Weimer likes this
Tarun Sapra
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 3, 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.

Yasmine Rifai January 26, 2014

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

Tarun Sapra
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 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.

Amine Teniou January 26, 2014

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
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 26, 2014

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

Yasmine Rifai January 26, 2014

@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
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 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.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 26, 2014

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
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 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.


Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 26, 2014

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
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 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.

Yasmine Rifai January 26, 2014

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

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 26, 2014

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
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 26, 2014

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

Tarun Sapra
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 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.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 26, 2014

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.

Alex Tabrizi October 5, 2015

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 !!!)

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 5, 2015

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"

Karen Hayden October 6, 2015

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?

Sai Gangadhar November 23, 2020

@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?

3 votes
Young Plugins March 3, 2014

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

Dominique Eav January 21, 2015

Working fine for us. Thanks!

Brijesh Jain May 19, 2015

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?

Young Plugins May 19, 2015

There is a manual on the website. Please read it and see if it works. Otherwise goto http://youngpluginssupport.uservoice.com/ and describe your problem.

Aurélie Narozniak January 18, 2016

Hi,

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

Eugenio Jose Martinez Ramos November 7, 2017

No cloud version yet :( 

1 vote
Sergei Gridnevskii
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 21, 2019

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.

1 vote
Renjith Pillai
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 2, 2012

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 http://forums.atlassian.com/thread.jspa?messageID=257250857

Tobias Hofer February 2, 2012

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...

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 2, 2012

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)

Tobias Hofer February 2, 2012

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.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 2, 2012

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)

Tobias Hofer February 2, 2012

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?

Valerie AQUILA June 10, 2013

@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 : http://forums.atlassian.com/thread.jspa?messageID=257250857

Where could I find it in the new forum ?

Thanks in advance for your help

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 26, 2014

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.

Renjith Pillai
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 26, 2014

The workarounds discussed in that forum (if I remember correctly) are there in this feature request - https://jira.atlassian.com/browse/JRA-5865.

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).

Yasmine Rifai January 26, 2014

@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?

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 26, 2014

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.

0 votes
Junio Fernandes December 27, 2017

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.

0 votes
archivisor July 28, 2016

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

Amir Katz (Outseer)
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 25, 2019

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

0 votes
Tarun Sapra
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 4, 2014

https://jira.atlassian.com/browse/JRA-5865

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

0 votes
Susan Alipour March 4, 2014

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.

Suggest an answer

Log in or Sign up to answer