Sometimes the scope of an epic changes to affect sibling groups / the parent group). The current workflow for those cases is to create a new epic and copy all issues individually, which leads to a poor user experience.
Intended users
Everybody who works with epics—so mostly managers but also developers.
Proposal
Create a /promote quick action that copies the epic (along with all comments, labels, issues, and child epics).
This action may expose confidential information if the child group is private but the parent group is public. We need to at least have a note (similar to moving issues).
What does success look like, and how can we measure that?
It's possible to move / duplicate epics to parent groups.
As you're promoting a single epic upwards and the epic itself isn't changing, I feel this is not only completely acceptable, but entirely expected. Under the covers, the "old" epic might still exist, but my instinct as a user is to assume it has moved entirely and visiting the old URL would redirect me to the new one.
My feeling doesn't, however, account for the potential permissions gotchas mentioned above. In our specific use case, there aren't any nested private groups to worry about.
I'm probably just rationalizing here, but I do think there's a difference, so long as we're only talking about promoting within the same group tree and not moving across trees arbitrarily. The epic would still be a collection of issues somewhere below it, but with additional potential scope and visibility.
Back to your original question about issue association:
If the old epic is closed in favor of a new one:
the issues will have the change in epic association in their activity trail, giving a link to the new epic
the old epic will have the moved issue notes in its activity trail, again giving a link to the new epic
If the epic itself moves up to a higher group:
the issues won't necessarily need an activity entry, but could have something noting the group change
the epic could/should have an activity entry noting the change
Either way, there should be a fairly good activity trail connecting everything together and allowing users to track what happened and not get lost.
You are welcome. Epics just happen to be top-of-mind for us at work right now—especially w/r/t groups and scope. We had a bunch of issues get promoted to epics, but it happened in a subgroup and we don't have a clean way to get them up where we want them.
In my real job, we use Ultimate and have found the scope limitations of epics to be a real drag, especially when issues are promoted. I really like the idea of being able to promote an epic "up the tree", if you will, and am very eager to see this happen.
Sorry (not sorry ) for the repeated pounding on this one, but I can't help myself as I keep running into the epic/group scope problem. Anyway, the original description mentions the permissions/security warning, so I thought I'd link to a similar issue regarding verbiage: https://gitlab.com/gitlab-org/gitlab-ee/issues/9215
Assuming the customer behind that Salesforce link is who I think it is (read: my employer), our use case is as follows:
We have a multi-level tree of groups and subgroups and projects, with all of our epics at the very top of that tree.
GROUP A
EPIC A.a
Subgroup AA
Project AA.1
Issue AA.1.a
Subgroup AB
Subgroup ABA
Project ABA.1
Issue ABA.1.a
Accordingly, any time we decide we need to promote an issue to become an epic, we need to get it from some indeterminate depth all the way up. Currently, that cannot be done. We can only get Issue AA.1.a as far as the parent Subgroup AA.
Since I last commented, we figured out a workaround:
GROUP A
EPIC A.a
Project A.1Added this project as a pass-through
Subgroup AA
Project AA.1
Issue AA.1.a
We move Issue AA.1.a to Project A.1. Thankfully, issue moves aren't limited by tree depth, so we can get Issues into this new pass-through project from anywhere.
GROUP A
EPIC A.a
Project A.1
Issue A.1.anew
Subgroup AA
Project AA.1
Issue AA.1.amoved
Then we promote the new Issue A.1.a to be an epic.
GROUP A
EPIC A.a
EPIC A.bnew
Project A.1
Issue A.1.apromoted
Subgroup AA
Project AA.1
Issue AA.1.amoved
The end result is what we'd like to see out of this issue, but we get a pretty ugly issue trail along the way.