nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JIRA: Is it possible to set issue assignee based on "Issue Type" automatically?

Gavin Fowler

I have a need to set the issue assignee automatically based on the "issue type" selected (i.e. out of box: new feature, bug, etc). I know this is possible through the use of components, but i really need to make determination based on issue type rather than component selection.

Let me explain further....

I have many jira projects (60+), where the use of components is widely accepted by my user community. However, for one project I'm attempting to use JIRA as a small service/helpdesk solution. Within this project, i have created a suite of new issue types like: "Faulty Printer", "Faulty Laptop", "Faulty Application". When a specific issue type selected, I show different different custom fields during the create issue process. This allows me to display specific fields for issue type. For example, I an issue type "Faulty Printer" is selected, I only show custom fields related to printers (i.e. a drop down list showing printer fault types). This all works very well and the users are pleased with the user interface.These users do not see components at the point of entry.

The one issue I'd like to resolve is how can i automatically assign the issue to a dedicated resource name i.e. "Bob Hope" when the issue type is "Faulty Printer".

I guess an alternative would be to automatically set a component "printer" (in order to leverage the auto assign feature of components) when a issue type is "Faulty Printer". I hope this makes sense??

I currently have the "JIRA Misc Workflow Extensions" and "JIRA Suite Utilities" plugins installed but as far as I understand that neither of these plugins support automatic assignee based on issue type.

does anyone have a method to do this? supported /free plugin would be preferable as i do not have budget.

thanks

Gavin.

Accepted answers

Justin Rand

JIRA can do this for you straight out of the box!

Create separate workflows for each issueType. Create a workflow scheme for your project mapping those workflows to the specific issueTypes. Then (in the workflows) using the stock post function "Update Issue Field", set your Assignee field to the desired user for each individual issue type in the "Create" transition.

3 things to note: 1.) To get to the "Create" transition, click on the "Open" step and "Create" should be one of the Incoming Transitions. 2.) When adding the post function, be sure to place it after the "creates issue originally" function or you will get some nasty errors. 3.) Be sure to delete the post function "Assign the issue to the reporter" otherwise your issue will get re-routed to the reporter.

All comments

Jobin Kuruvilla [Adaptavist]

You can write a JIRA Listener that does the same.

Gavin Fowler

Thanks for the quick reply Jobin! I'm not really a developer, do you know of any good resources where i can view custom listeners in JIRA 4.0 (preferably with examples)?

Jobin Kuruvilla [Adaptavist]

Checkout this tutorial : https://developer.atlassian.com/display/DOCS/Plugin+Tutorial+-+Writing+event+listeners+with+the+atlassian-event+library

Gavin Fowler

Many thanks! It will take me some time to absorbe this information, but it's defintily the runnign start i needed. perfect!! appreciate the support

Samuele Pretini

I thinks that you can create a Workflow post-function instead.

I have created a similar post-function for set the Estimate Time based on Issue type. You can, in the same manner, do your work.

Really you have to develop your own post-function, package it and install as plug-in in Jira, but all is very simple. You can read the documentation about developing the custom plug-in.

Bye.

Samuele

Gavin Fowler

Many thanks - i'll look into plugin creation (dust of that old developer hat). Any advice on quality resources to review would be very useful / appreciated (or code snippets by PM?) wld be most welcome

Justin Rand

JIRA can do this for you straight out of the box!

Srini Srini

This will be the quick and straight forward option and will work if you know who the issue has to be assigned to. If the user has to be changed later you just have to update the workflow.

This is the pretty simple solution.

-Srini

Sander Brienen [Avisi]

We always advise to minimize the use of plugins as much as possible. If it can be done with out of the box content, then choose that solution. Plugins will once get in your way when wanting to upgrade to a newer version of the product. That is the reason I voted up the third answer. I think it is a better solution.

Drew Peifer1

I've upvoted Justin Rand's answer because it really is the easiest, most light-weight solution to your problem. I have the same issue myself, and it took me about 20 mins to implement and test the solution listed below.

However, I now have 2 more workflows than i did 20 minutes ago. If every department in my company wanted this functionality, we would easily have over 50 workflows for less than 30 projects. The JIRA-mindset for this problem seems to be catering to the use of issue type schemes, screen schemes, etc. to create a hierarchy of events and conditions that automatically modify workflow actions in the background. The problem with this is that it makes even minor problems incredibly hard to debug unless the debugger is also the workflow creator, because a single field may act differently from project to project, issue type to issue type, screen to screen, etc. and you have to debug from the bottom up, checking field permissions, screen configurations, project contexts, etc. The complexities of these hierarchies can be VERY intense, even if the end-result is a minor change in field behavior.

We currently avoid multiple workflows (in some cases) by adding extra transitions to the workflow with unique labels, and while the transitions are basically the same, each has a unique post function. E.g. A tester may click "ready to test in environment B", which just changes status (because code passes environment A), but a developer would click "available for testing in environment B" which adds a post-function notification event to alert testers to the code's availability in environment B. This requires testers and developers to understand the post-functions though, and is error-prone.

A simple solution (that is currently impossible out of the box for JIRA5.x) would be to create conditional post functions such as...

if (issue_type == 'johnsIssue') {assignee == 'userJohn'} else {assignee == defaultAssignee}

to my knowledge, this is still not possible in JIRA5.

Mark Bednarski

I know this is an old post. But I was right now looking for a solution as I have the exact same problem. I will try to use Script Runner plugin as I need this for many other things as well.

The general recommendation seems to be to use different workflows. But this is producing a huge overhead if you want to change your workflow and you have to do the very same change on multiple places again and again.

Ian Mayoh

Couldn't agree more! I have 2 near-identical workflows and the only reason is that I need specific issue types to go to different people otherwise I could use the same workflow. Means twice the effort if I need to change anything common to both and I need to make sure that I make the same change(s) to each --> user errors! Having conditional post-functions would solve this and other issues that I have.

Paul Goodsell

This fix works great elsewhere in my workflow but when I place it on the transition between 'Create' and 'Open' it tricks the transition from 'Open' to 'Allocated' into thinking that the issue has already been assigned. Thus, it misses a state. Does that make sense? Anybody know a fix?

randyz

In 5.x, when adding this post function it must come before "Creates the issue originally".

Peter Milakovich

There's a ticket open since 2004 that may eventually address this:

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

Shane Day

Well, it should be addressed sometime this millennium.

David Skreiner2

Since only 170 people voted for the feature, it'll never be implemented. They closed that 2004 issue as a dup now, instead pointing to an issue from 2008. The new one has less than thirty votes. https://jira.atlassian.com/browse/JRA-14897

(Some of the more popular issues have Thousands of votes ... Not sure if these might be faked by someone telling all his colleagues to vote for a feature, or other unfair methods.)

David Skreiner2

LOL, difficult. I totally agree on your "use as few plugins as possible" stance for financial and security reasons. Unfortunately Answers makes it look like Atlassian would disagree:

Many users here on Answers are plugin developers who are mainly out to make a quick sale. I've seen questions on here where an easy workaround without plugins exists ... but no one said so, instead they offered two different commercial plugins.

This is very harmful to Atlassian's reputation in my view – even in the JIRA Admin course I took years ago, I was warned about missing features and glaring bugs which require expensive addons to fix, about users requesting stuff that I won't be able to implement without spending a lot of money, and the guy even ranted about how Atlassian never fix problems if there's a paid addon that they can sell instead. While that trainer was obviously frustrated and exaggerated a lot, I quickly got to understand how he got that impression.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

issue-type

assign