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.
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".
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.
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.
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.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Every time you release software, there's a bit of risk – that there's a bug, that something breaks, or that the feature doesn't resonate with customers. Feature flagging helps make high stakes s...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs