Block group of users in creating / closing certain issue type

Question

Hello,

Currently we face the problem that many of our developers just pollute the JIRA backlog with creating Epic,

User stories add hock. Is there a way on how I can prevent a certain group of users in creating Epic's (we would like this to be owned by PLM and PM) and user stories?

Related to this question we would also like that developers could only close sub-task of user stories and tasks, but not the issue types task, story and Epic.

Nic Brough -Adaptavist- · Answer

I've worked in similar environments for years.  I've always found education to be the better route than enforcement, but there are times when you just have to do it.

Bryan McMillan_mmet0u · Answer

Nic,

Thanks much for your input!  Oh how I wish JIRA instances were in the constant JIRA user friendly environment. Then I would be very first in line to agree with you.  However, such is quite often the obverse.

There seems to always be one, two, three or more rogue users who won't follow process, refuse to collaborate, insist on always being first or being right, and of course the new folks who have only been in the organization a short time or just starting using JIRA this week and on I could go.  Thus, we oft find ourselves having or needing to setup "don't do that rules" to prevent the inevitable as much as humanly possible.  This becomes even a larger problem if the JIRA instance is in an environment constantly inundated by nearly continuous audit/compliance requirements.  Given that several of the available plugins provide tremendous flexibility to setup and enforce a checks-n-balances system, it helps to enforce a base set of rules to prevent many errors. Add to that a set of filters/notifications/subscription functions you can easily put in place to institute a self-policing system where one can prevent many of those nasty, "you shouldn't have done that problems" providing training opportunities for correction  And lastly, if you have to institute any form of quality gates one again finds themselves relying on those plugins to enforce those.  Is it a friendly way to setting things up?  No, in that you are quite right.  But it sometimes is practical and even more often that not, required to implement.

Sincerely,

Bryan

Nic Brough -Adaptavist- · Answer

It's better to use Conditions later in the workflows - that stops people from having the option to close them, whereas a validator would let them start the close process and then give them an error message, which is not very friendly.  Also, you don't need any coding for Conditions for groups or roles.