permission to create specific issue type

[Tobias Hofer]

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

[Nic Brough -Adaptavist- · Accepted solution]

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.

[Amine Teniou]

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]

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.

[Tarun Sapra]

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]

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

[Tarun Sapra]

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]

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]

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

[Yasmine Rifai]

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

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

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]

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

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!

[Tarun Sapra]

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]

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

[Nic Brough -Adaptavist-]

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]

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

[Tarun Sapra]

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

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]

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

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]

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]

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

[Young Plugins]

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

[Dominique Eav]

Working fine for us. Thanks!

[Brijesh Jain]

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]

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]

Hi,

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

[Eugenio Jose Martinez Ramos]

No cloud version yet :( 

[Sergei Gridnevskii]

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.

[Renjith Pillai]

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]

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

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]

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

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]

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]

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

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]

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]

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

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.

[Junio Fernandes]

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.

[archivisor]

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

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

[Tarun Sapra]

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.

[Susan Alipour]

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.