## Release notes As a continuation of improving cross-functional workflows, you can now [add child epics from unrelated groups to a parent epic](https://docs.gitlab.com/ee/user/group/epics/manage_epics.html#child-epics-from-other-groups). Prior to this change, Epics can only contain sub-epic children which are in the same group. This is limiting and inconvenient for users who are trying to manage, organize, and communicate on large scale projects that have different sub-initiatives in other groups. ### Problem to solve Prior to this change, Epics can only contain sub-epic children which are in the same group. This is limiting and inconvenient for users who are trying to manage, organize, and communicate on large scale projects that have different sub-initiatives in other groups. This work is the MVC for enabling the relationship between a parent epic and children in other groups. #### :crystal_ball: ## :crystal_ball: Context MVC one scope as [defined in the epic](https://gitlab.com/groups/gitlab-org/-/epics/8294#mvc-2-child-epics-from-a-different-hierarchy "Epics can have issues and subepics assigned from different Group"): > * From within an epic, paste a URL for an epic in another group that you have access to make it a child. > * We shouldn't worry about searching/autocomplete. There could be performance concerns with this workflow and customer feedback is that this is not their preferred path to create parent/child relationships. > * The epic tree should redact epics,subepics and issues that a user does not have access to. > * In ancestors in the sidebar for epics, the parent/ancestor epic should be redacted if the user does not have access to that epic's group. > * In the roadmap, the epic name should be redacted if the user does not have access to that epic's group. It should be included in the rollups for item count and % complete. ## [Rollout Plan](https://gitlab.com/gitlab-org/gitlab/-/issues/382719#note_1172514546 "[Feature flag] clean up child_epics_from_different_hierarchies") * [x] Now (end of %"15.6"): Enabled for plan testing groups [`product-planning-test-group`](https://gitlab.com/groups/issue-reproduce/product-planning-test-group), [`plan-test-group`](https://gitlab.com/gitlab-examples/plan-test-group) and [`plan-stage`](https://gitlab.com/gitlab-org/plan-stage) * [x] During %"15.7" and after https://gitlab.com/gitlab-org/gitlab/-/issues/373713 is done: Enable for `gitlab-org` and `gitlab-com` groups (using a rollout-percentage) * [x] During %"15.8": Enable the flag for `Gitlab.com` and `Gitlab.org` * [x] During %"15.9": After https://gitlab.com/gitlab-org/gitlab/-/issues/384265 is closed, enable flag globally for 2 weeks. After this time enable it by default if no incidents (MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111035) * [x] During %"15.10": Clean up the feature flag (issue -> https://gitlab.com/gitlab-org/gitlab/-/issues/382719)