Recommended configuration for cascading / parent dependent field ?

Huy Pham

Hello all, my company is migrating over to using JIRA. We are setting up the workflow and fields, but we are working with an independent contractor to help with the migration of our data set.

Wanted to ask the JIRA community advice on how we're planning to handle the configuration for our Component and Category fields.The requirement is for the Component value (single value) to populate the values available for the Category field (also single value).

Example: If Component = Client, Category list = Authentication, Branding, Help, Install, UI, ...

The current plan was to use the Select List (cascading) type to configure our Component/Category field, since this seemed like a good way to handle the requirements.

We were advised by our contractor to go with a custom scripted field to handling the cascading values. He recommended this because he found the field didn’t work well with the Issue Navigator or Dashboard gadgets

What is the current opinion on how we should move forward? We would like to pick a solution that is common enough to continue relatively easy maintenance for the future.

Thanks all.

Nic Brough -Adaptavist-

I would be interested to know why your contractor does not recommend the use of the "Select list (cascading)".

It's a standard field in JIRA that has been there for many releases and is very unlikely to be pulled out without Atlassian replacing it with something better (and providing a migration path too)

They may be talking about other addons that provide more advanced cascading selects - these may have worries about future support, but the ones that have been around for a while do not look like they are going anywhere either.

So, the simple answer is probably going to be "use the built in cascading select list", but I'd ask your contractor to expand on their concerns - there might be good reasons that I've not picked up on from your question.