### Problem to solve > *As a User of Epics,* > > *I need to be able to assign an issue or subepic to my epic even if it belongs to a different group*, > > *So that I can properly organize, manage, and communicate how much work is involved with a specific Epic* ### Intended users * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) ### Further details Per a discussion with @jstava: > *Growth is in a sub-group and I can't add issues in the regular gitlab org to my epics and some of our MRs have to be created in other groups like the gitlab org or the data org groups. I have Epics that have issues in 3 different groups and I can't link items outside of the group my epic is in.* There was also a [session with our BIZOps group/@j.carey](https://docs.google.com/spreadsheets/d/1rUk9hxTeerpJwsZKJfdts_uumu-nNaNHmwwdyHg_17E/edit#gid=2113127156) (thanks @tipyn!), where this need was discussed: > *One of our biggest challenges is trying to project manage between two groups and the hierarchy that is enforced between issues in different projects.* > > | Research Questions | Answer | > | -------------------------------------------------------------------|------------------------------| > | Which aspects of GitLab would you want us to prioritize improving? | cross group relating to epic | > | What would help you in the short-term? | cross group relating to epic | > | What would help you in the long-term? | cross group relating to epic | ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> - Allow any issue or epic to be the child of an epic in a sibling group or completely different group hierarchy. - The existing rollup behavior remains the same across all children of an epic. #### MVC 1 - Child issues from a different hierarchy * From within an epic, paste a URL for an issue 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. * For this initial iteration, we don't need to worry about adding epics from another group but we will want to fast follow with this. * Most of the focus for this MVC will be to figure out how to present `User doesn't have permission to view other group's epic` to the user in a way that is meaningful. * Feedback that I have gotten from customers is that the epic/issue name is confidential in itself so we'll need to redact that in all places where it could show up for someone that does not have access to that group/project. * Text display in the Issue sidebar where the parent Epic is displayed should be redacted if the user does not have access to that Epic. * All child issues should continue to be considered in date calculations regardless of the project they belong to. * We should allow a user to change the parent epic, but they cannot change it back to the originally redacted epic if they don't have access to it. * We should allow a user to remove an issue, but they cannot add back a redacted issue if they don't have access to it. * When viewing an epic some issues may be in a project you don't have access to, we should redact the issue name. * When viewing an epic in a roadmap issues may be in a project you don't have access to, we should include those issues in the calculations for percent complete #### MVC 2 - Child epics from a different hierarchy * 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. #### MVC 3- Improve the searching experience for items outside your current group/project hierarchy ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> - In order to view the epic or issue from another group/hierarchy, the user must be a minimum of a `Guest` user in both groups. - If the user does not have access to that issue/epic the information should be redacted. This will apply to the parent Epic selector in the sidebar, Ancestor view in the sidebar, Roadmap, and Child Epic/Issue Tree. - Question - Are there other places that need to be considered? - When an issue/epic is redacted, there should be a placeholder row in the Ancestor view in the sidebar, Roadmap, and Child Epic/Issue Tree. The epic will not be clickable and the title text should be replaced with "Private". Hover over text should explain the use does not have access to this resource. - Question - Is redacting the title necessary? - [Customer](https://gitlab.my.salesforce.com/00161000015O9Yn) feedback is Yes - Question - What should the redaction title be? - [Customer](https://gitlab.my.salesforce.com/00161000015O9Yn) recommended looking at Slack for their UX - If an issue/epic has a parent that is redacted, they can change the parent epic to one that they have access to but they cannot change it back to the redacted one. - If an issue/epic has a child item that is redacted, they can remove the item. - ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> Yes ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ### Links / references Slack UX: