Would I run into problems by using a single Issue Type for my project, and hiding that field?

[Brandon Eldridge]

I have to walk a fine line between ease of use, and analytics power in my project.

Currently, my project has two Issue Types. Depending on which is selected, the available options within a cascading multi-select field will change.

The cascading multi-select field essentially functions the way Issue Type and Component are supposed to. We have to go this route though because we handle too many things per Issue Type, the Components list would be too unwieldy.

So, for ease of use, we have decided to split the two Issue Types into two new, separate projects. I was going to just do away with the Issue Type for each project entirely, but Jira forces one to be available. So my workaround is to make a single Issue Type with the same name as the project, and then hide that field from the ticket creation screen.

The way I figure, when I pull analytics, I can just use issuetype = myteam instead of project = myteam. If I run project = myteam, the only stat I will get will be the number of tickets created for the sole issue type, with no categories broken up on the chart. But if I run issuetype = myteam, then I should see the categories within the Issue Type, as defined with the cascading multi-select, broken up on the chart?

Right? I don't mean to answer my own question, haha.

I just want to make sure that there won't be any ramifications from doing this later when I try to pull statistics. Any assistance would be greatly appreciated!

[Bart D]

What are you trying to achieve in regards to analytics? What is your end goal to report?

Seems really messy to be creating an issue type that is the same name as the project. 

[Brandon Eldridge]

I need to be able to pull reports for tickets created based on the selections in the cascading multi-select, concatenating several selections based on options in the multi-select field, the entire issue type divided up by categories based on the multi-select, etc.

These are all things I can do now, but there's a bit too much wizardry involved on the backend to make it easily scalable in the long term. Right now, we can only run reports with meaningful results on either Issue Type A or Issue Type B, we are unable to pull a single report to compare tickets for a category from one Issue Type to another Issue Type, because of the way we are set up at the moment.

I wish I could just do a normal Issue Type and Component setup, but I would end up with a 200+ option Component list.

[Bart D]

A screen shot would be worthwhile in regards to what you screens look like and options. How we can group and simply this. I feel like custom fields would be a good option for you. 

[Brandon Eldridge]

This is how we're set up now. Thank you for looking into this with me.