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 OnDemand - Mail Handler Issue Creation - Multiple Issues w/ different Workflows

jzschau

We're using OnDemand and need to have the mail handler create issues based on incoming emails -- you're typical helpdesk scenario. Email comes in and default assignee is unassigned. Unassigned issues are reviewed and assigned out to appropriate individuals to be handled. The only problem is that we have several different workflows associated with different issue types. When an issue is created by the mail handler it needs to set it to a Default Issue Type (configured within the mail handler). Unforatunately, once the default issue type is set there's no easy way to change the issue type to any of the types belonging to other workflows -- we get that: "Some issue types are unavailable due to incompatible field configuration and/or workflow associations" message and the only issue choices from the issue edit screen are those that belong to the same workflow as the default issue type (as set in the mail handler). Sure, we can MOVE the issues, but this is not a viable option for us.

I'm guessing that I'm missing something extremely basic here because if this cannot be further configured then the OnDemand Mail Handler wouldn't be functional for use on projects with more than one workflow -- which is one of the main selling points of JIRA. Any assistance would be appreciated. Thanks!

Accepted answers

All comments

Nic Brough -Adaptavist-

No, you're not missing anything here.

I would break down the problem into two pieces though.

First, the mail handlers can only set one project/issue type. If you want a single mail box to be able to create different issue types, then you need a handler that can do it. There are options for download users, but I'm afraid you are stuck with OnDemand - you can't install other handlers (frankly, if someone says "Jira" and "incoming mail" in the same sentence, then the answer is JEMH)

Second, the change of issue type. This is the same across all Jira installations. You have to "move" the issues because Jira needs to force you to validate the data you are changing or deleting because your issue types are too different to do it automatically. There's no "easy" way to do it because you've set up incompatible issue type structures. You might find it cumbersome, but there's no real alternative - I've been asked to look at this a dozen times, and no matter what you do, you end up having to go back to your users and say "if you want to bypass this move process and do it automatically, then you all need to agree on what data you want to lose or set to some agreed default".

For your case, the options are:

Change your process so that move becomes "viable" - look at the reasons move isn't usuable for you.
Set up separate email addresses and boxes for the incoming mail. That can include pre-processing outside Jira (Jira reads 5 mailboxes, your users email the sixth. There's a service running somewhere that scans box 6 and moves the emails to one of the other 5 as appropriate)
Change your setup so that you don't need "move" and can simply edit - make the configs compatible/

jzschau

Thanks Nic. It sounds as if our only option would be to install JIRA on our own instance and use something like JEMH. Do you happen to know if JEMH supports the type of ticketing process we're attempting to create?

Basically upon email receipt we want it to generate an Issue that doesn't have Issue Type defined. That way when the issue is reviewed by someone and edited for the first time (and assigned to an individual) the full array of issue types will be available to choose from and, therefore, we could take full advantage of having differing workflows for different issue types without needing to move issues.

Nic Brough -Adaptavist-

I have not tried it, but I'm pretty sure JEMH does "if email matches X, then create with issue-type Y"

However, your follow-up says "generate an Issue that doesn't have Issue Type defined" - that is quite simply impossible. If you create an issue in Jira, it MUST have a type. End of story. It is not optional, because all the config hangs off the type.

jzschau

Thanks again for all of your help, but I'm still very confused. I've spent some time this morning reading up on JEMH and haven't been able to find any mention of what I'm trying to do. I'm trying to create an issue intake process where someone could email a single address and JIRA will generate an unassigned issue. I've been able to do that.

From there, I need a would-be support rep to be able to review the issue and make a determination as to a number of different fields (e.g. Issue Type, assignee, some custom fields, etc.) and begin work. The issue type simply cannot be determined until someone reviews the incoming email. We cannot have one issue type because there need to be different workflows. If this involves creating a default "dummy" issue type (i.e. None Selected) that would be fine, provided there is a way to make issue type None Selected "compatible" with all possible workflows and, therefore, all other issue types would appear in the drop down list upon issue edit, but I have yet to figure out how to do this.

Nic Brough -Adaptavist-

It's not going to work.

As I said before, the issue type is completely and utterly mandatory, because the configuration needs it so that Jira can handle further data. There is no choice, no workaround here, you have to have an issue type.

So, yes, you could happily create one called undecided, or none selected (or even penguin), default to creating them, and do your reallocations later. But you can't make it generically "compatible" with other types because the configuration for issues is hanging off the issue type. Which you will be changing later, mandating a "move" because you have set up your types too differently to be handled automatically.

Your options here are limited:

Use JEMH to correctly decide upon the right issue type BEFORE your support rep gets to them
Modify your issue types so that they are edit-compatible
Accept that your "move" process is the only "viable option" and train your users to get it right
Find or write a listener that can handle the "move" for you when it gets an "issue created" event. This, by it's nature, is going to mean you hard-coding business logic into it, to get around all the questions "move" needs you to answer in order to change the issue type

jzschau

Hi Nic. Thanks again. I've figured out a solution that seems to work for me using conditions based on a custom field value. Instead of creating multiple issue types for the issues requiring different workflows I created a single issue type for the group and used a custom field to further classify. Then, based on that custom field I was able to set up conditions within a single workflow, which accounts for the variations I was trying to create using different issue types. Thanks again.

Nic Brough -Adaptavist-

option 3 with clever stuff then :-) I was going to ask what the differences in your workflows and fields were next to see if we could merge them.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud