I think the solution to my question is to set the Issue Type Hierarchy but due to the message "Moving or changing hierarchy levels of issue types will break existing parent links in all company-managed projects in your site. This change can't be reversed." I'm concerned that I may break the linking within other projects in our instance of Jira which I need to avoid if at all possible. The parent / child relationships in the other projects are only subtasks to issues.
My goal is to properly account for the following hierarchy in my project while reviewing the plans and Roadmap with: CIT (top level in my project), Resolution Plan, Milestone, Sub-Task. So, in the plan hierarchy view I want to be able to have a CIT with child resolution plan issues as dependencies, which will have Milestone issues as dependencies to those.
Currently the hierarchy is set: 2 Resolution Plan, 1 Epic, Story, Sub-Task. Note, Story and Sub-task do not have hierarchy numbers by them.
My Questions:
1. If I modify the hierarchy will parent child relationships in other projects break if I use the final hierarchy as: 1 Epic, 2 CIT, 3 Resolution Plan, 4 Milestone, Story, Sub-Task?
2. If it will break the parent / child relationships in the other project is there another way to accomplish my goal?
Hi @Matt Houck
I'm a little confused on the need, but I've assumed from the question you want to:
---
The bottom 3 levels (Epic, All Other Standard Issue Types, All Sub-task Issue Types) are locked in place - so it's not possible to move the Epic to the top.
But, you could still achieve what you need:
^ This should have zero impact on the rest of the hierarchy - as you've added a layer which wasn't there previously, and not modified any of the current layers.
---
A few notes on this approach:
---
I'd still test this of course, in your Sandbox, but the above should work.
Let us know how it goes :)
Ste
Thank you so much for responding and reading through my gibberish!
I think what I am reading is that I can add new levels of hierarchy without causing linking to break. Is this true?
The effect may be that additional levels may show up in roadmaps that may need to be filtered out of projects that do not use the levels I create.
You mention sandbox. This is interesting as I am not aware of the sandbox so I will look into this more. This might be exactly the thing I need to test this out!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Matt Houck
Yes - the hierarchy should not break if you are adding...
^ Of course, there are circumstances where you could break it - for example, adding a layer inbetween two existing layers, or removing Issue Types from existing layers - but neither of those examples seem relevant to your requirements!
I would still encourage testing it in your Sandbox first though. Sandboxes are available to you if you have a Jira Premium or Jira Enterprise licence. Check out more on this page - Manage product sandboxes.
Ste
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for the responses! I had some vacation time I was using last week but will work on it this week and if everything goes as expected I'll accept the answer! Thanks again for bearing with me!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.