Block group of users in creating / closing certain issue type

Daniel Vangrieken December 11, 2015

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.

3 answers

0 votes
Bryan McMillan December 11, 2015

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-
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 11, 2015

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.

0 votes
Bryan McMillan December 11, 2015

Daniel,

 

If you have the ScriptRunner Plugin installed, you then can setup a validator on the Create transition requiring the following criteria to be valid that requires "Only users with Create Issues permission can execute this transition."  Then place all of the users who are not offenders in that group so only they can create those issues. For example a group called, "Can_Create_Issues_Grp" or for your situation maybe have a "PLM_PM_Grp" for just the Epics.  This assumes that Epics have their very own workflow not shared by Story Issues.  You can use a very similar setup to control who can close them by project role or group.

Regards,

 

Bryan

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.
December 11, 2015

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.

0 votes
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.
December 11, 2015

There's no easy way to stop users creating certain issue types (you can play tricks in the workflow like having validators or screens that fail, but that's very ugly for them)

The best answer is actually to educate the users to do your process properly.

On the second point, that's easier - change the workflows for the protected issue types, adding conditions that say "on;y X can use the close transition". 

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events