-
Bug
-
Resolution: Unresolved
-
Medium
-
None
-
8.20.10, 8.22.4, 9.6.0, 9.11.0, 9.4.9, 9.12.5, 9.12.8
-
8.2
-
24
-
Severity 3 - Minor
-
23
-
Issue Summary
When an issue has a Parent Link and its issue type is changed to a type on another hierarchy level, the Parent Link data remains. Consequently, the Parent Link is still visible on the issue view with a warning icon that suggests the Parent Link violates the current Hierarchy configuration and should be updated by the user.
This issue is worsened when an Epic Link is also present on the Issue that had the Issue Type changed. The presence of an Epic Link makes Jira automatically hide the Parent Link from the Screens and makes it harder to remove the leftover data.
This issue can lead to unexpected and unusual behaviour in Jira. For instance, JQL queries may produce results that differ from what is anticipated. For example, 3rd party app that provides JQL functions to iterate over the Issue hierarchy (linkedIssuesOfRecursive) and can return a different set of issues than Jira functions like(childIssuesOf).
Steps to Reproduce
Scenario 1
- Create a new issue type called 'Initiative'
- Configure the hierarchy to be above Epic (at the top level)
- Create a new issue with the issue type 'Initiative'
- Link an Epic to the new Initiative using the parent link
- Open the Epic and use More > Move to change the issue type to 'Initiative'
Scenario 2 (inconsistent results returned from childIssuesOf(...) query)
- Create a new project.
- Configure the hierarchy like this:
- EpicBusiness -- Capability --- Epic ----Story
A) The experienced Issue follows the below scenario ...
- The Capability CAP-100 has the EpicBusiness EPB-100 as Parent.
- The Epic EP-100 has CAP-100 as Parent
- The JQL
issue in childIssuesOf(EPB-100)
returns CAP-100 and all its child : Epic (EP-100), User Story (...), Sub-Task (...)
B) A user move CAP-100 as an EpicBusiness : EPB-110
- The JQL
issue in childIssuesOf(EPB-110)
returns always same children as when it was CAP-100 - The Epic EP-100 has EPB-110 as direct Parent, an EpicBusiness ! Normally, only Capabilities should be allowed as Parent of Epic
- The JQL
issue in childIssuesOf(EPB-100)
returns always same children, including EPB-110 (ex-CAP-100) ! Normally, an EpicBusiness can not have a EpicBusiness as Parent.
It is causing many inconsistencies in the users activities
Scenario 3 (involved 3rd party plugin)
1. Install a 3rd party app that provides JQL functions to iterate over Issue hierarchy
2. Create Issue Types "Initiative" and "Capability" and add them to a Project's Scheme
3. Add the Parent Link Custom Field to all Screens on that Project (to make it easier to follow the steps)
4. Configure the Roadmaps Hierarchy so that Initiative > Capability > Epic
5. Create a set of Issues organized as such:
Initiative 1 Capability 1 Epic 1 Story 1 Capability 2 Epic 2 Story 2 Epic 3 Story 3
6. Create a Filter using the 3rd party app JQL function to list the Hierarchy of the top Issue, like:
issue = "<Initiative 1 Issue Key>" OR issueFunction in linkedIssuesOfRecursive("<Initiative 1 Issue Key>", "is parent of")
7. Confirm all Issues under the hierarchy of "Initiative 1" are listed
8. Change the Issue Type of "Capability 2" to Story (Move operation also works) and set it's Epic Link to "Epic 3"
9. Reload the Filter and see "Capability 2" (now a Story) is still being listed, though it's now in the Hierarchy of "Epic 3", not under "Initiative 1"
If you use Jira's native JQL functions, the Epic Link has precedence over the (invalid) Parent Link and "Capability 2" is not listed anymore:
issue = "<Initiative 1 Issue Key>" OR issue in childIssuesOf("<Initiative 1 Issue Key>")
Expected Results
- The parent link will be cleared as you should be able to only link an issue to a parent issue of the corresponding hierarchy level that you've configured for your plan.
- A Move Issue with change of Type (in Roadmap Hieararchy) must break all Parent Links or be blocked while a Parent-Child link exists
- A Move Issue between JSW Issue Types and JPO Issue Types should be follow same rule
- The JQL childIssueOf() should return children in respect of Hierarchies. Parent Link between Issue Type in same Level hierarchy should be ignored.
Actual Results
- The parent link data remains.
- The parent link can't be edited as there is still Epic Link
- The "Capability" Issue has a valid Epic Link which is prioritized by Jira and an invalid Parent Link which is ignored.
- The data is still left over in both DB tables:
issuelink entity_property
- The JQL childIssueOf() return the same results after move the ticket to another parent hierarchy issue type.
Workaround
1. Create an automation to remove the Parent Link
Create an automation rule that will automatically clear the Parent Link field whenever an issue is moved to a new issue type, as explained in the KB article linked below:
2. Remove Parent Link manually
To remove the parent link:
- Convert the issue back to its previous issue type(e.g. Epic).
- Remove the parent link.
- Convert back to the new issue type.
3. Remove existing data directly from the database
To clean up existing Issues' Parent Links refer to this documentation:
- is duplicated by
-
JPOSERVER-2895 Converting an issue's type to the same level as its Parent does not relinquish its existing Parent link as it should.
- Closed
-
JPOSERVER-4360 When converting an issue from Epic to another issue type, the parent link field is not cleared
- Closed
-
JSWSERVER-21939 Clear the Parent Link data when the Issue Type is changed and the Link isn't valid anymore
- Closed
-
JPOSERVER-7116 Clear the value of "Parent Link" field when creating a new issue
- Closed
- is related to
-
JPOSERVER-4360 When converting an issue from Epic to another issue type, the parent link field is not cleared
- Closed
-
JSWSERVER-21939 Clear the Parent Link data when the Issue Type is changed and the Link isn't valid anymore
- Closed
-
JSWSERVER-24981 Bulk Move causes Parent Link to break
- Gathering Impact
- was cloned as
-
JPOSERVER-7116 Clear the value of "Parent Link" field when creating a new issue
- Closed
- links to
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...