Move an epic to another group via quick action

Problem to solve

Sometimes the scope of an epic changes and is either narrower (only affecting a subgroup) or wider (affecting sibling groups / the parent group) afterwards. The current workflow for those cases is to create a new epic and copy all issues individually, which leads to a poor user experience.

Proposal

We should support moving epics to other groups like we do for issues. As a first iteration of this, we should support moving epics via the /move quick action.

/cc @victorwu

Hi @winh,

First of all, thank you for raising an issue to help improve the GitLab product. We're sorry about this, but this particular issue has gone unnoticed for quite some time.

We're posting this message because this issue meets the following criteria:

• No activity in the past 6 months (since 2018-07-11T15:33:32.091Z)
• No milestone (unscheduled)

We'd like to ask you to help us out and determine how we should act on this issue.

If this issue is reporting a bug, please can you attempt to reproduce on the latest version of GitLab or GitLab.com, to help us to understand whether the bug still needs our attention.

If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.

Please mention the Triage team (@gitlab-org/triage) for help with applying labels

Thanks for your help!

---

You are welcome to help improve this comment.

added auto updated awaiting feedback labels

@victorwu Are there already other plans regarding this?

changed milestone to %Backlog

added [deprecated] Accepting merge requests label

removed awaiting feedback label

@winh no, we don’t have plans for this specifically now. I think it’s a good feature. Putting gitlab-ce~1890178 and %Backlog.

removed auto updated label

Since Epics belong to EE, move this issue to the EE repo.

changed milestone to %Backlog

I'd like to see this as an enterprise customer. We've had a lot of need for this, instead we are left re-creating. Perhaps just supporting promoting to parent group would be sufficient of us.

added customer+ label

@ebrinkman

• A 300 Ultimate client would like this to be included in the near future since it's impacting their workflow negatively.
• Salesforce link: https://gitlab.my.salesforce.com/0016100000W3B8A
• Why interested: Part of their workflow includes creating Epics and moving them to other groups at certain times.
• Current solution for this problem: Recreating epics manually, which is very time consuming (doesn't scale)
• How important to them: Very, and it's an ultimate feature so if they lose interest, renewal time will be bad.
• Questions: How far out has been planned for the plan phase? Is there a chance this will hit 12.4 or .5 or will it be a long time out?

@mterhar Could you please comment here what information of an epic the customer would like to duplicate? Is this only about the title, description, and labels?

The epics are typically created in a group for planning broad strokes. The epic will be given sub-epics that flesh out the plan into finer detail.

At this point, the epic is ready to be put into its own new group or an existing groups where issues will be added to define the detailed implementation.

They’d probably like the ability to clone so they can start from a pre-defined structure... though that’s less important than the movement between groups.

@mterhar If the epic is moved, neither relations to issues nor other epics can be kept (because we currently don't allow them across different groups). Would it still cover their use case without them? Or are they mainly interested in the epic-child epics-issues tree structure?

@mterhar I assume their use cases are covered by https://gitlab.com/gitlab-org/gitlab-ee/issues/9398 or https://gitlab.com/gitlab-org/gitlab-ee/issues/9243.

I just found that my reply to your last message on this thread didn’t post... then I accidentally cleared it.

There are increments of success and each one helps support the end user. Cloning is great. Moving is great. Templating is great. Being able to copy or reference child epics is great. Cross-group issues is great.

I think any of those will improve the clients workflow.

Those two specific issues are a great start and will be very beneficial.

@smcgivern @donaldcook I'm going to schedule this for %12.2 as there was some mention of extra capacity. If this can't be accomplished we can push it to %12.3.

@mterhar we will get to this in the next few releases.

changed milestone to %12.2

added backend frontend labels

changed milestone to %12.1

@cablett and I have discussed that this is a good issue to start my backend internship (https://gitlab.com/gitlab-com/people-ops/Training/issues/344). So I will look into it in %12.1 already.

assigned to @winh

@ebrinkman The scope of this issue is quite vague (sorry! ), so I'd like to suggest the following:

• introduce the basic functionality for moving epics and a quick action /move (similar to issues)
• leave UI for a separate follow-up issue

This would allow us to get the basic functionality to our users faster but also give us the chance to further discuss how the UI is supposed to like like. What do you think?

@winh I've updated the issue title and description to narrow the scope for you. I'll also be creating a new issue for UI functionality.

changed title from Support moving an epic to another group to Support moving an epic to another group via quick action

changed the description

changed title from Support moving an epic to another group via quick action to Move an epic to another group via quick action

removed [deprecated] Accepting merge requests label

changed milestone to %12.2

I'm setting the weight of this to 3 (2 + uncertainty of 1).

@cablett would you agree?

Agree @winh ! That's the weight I would assign as well

changed weight to 3

added to epic &1715

changed milestone to %12.3

added groupproduct planning label

added Enterprise Edition label

There are a few UX concerns that I didn't really think through earlier and that now popped up when looking into the implementation.

First of all, there are two fundamentally different ways to achieving the goal:

1. "physically" move the epic (delete it in the old group, create a duplicate in the new group)
2. clone the epic (close it in the old group, create a duplicate in the new group)

Initially my thought was to go with 1. but I assume now we want to go with 2. because that is consistent with the /move action for issues and also allow users to still look at the old epic even if they don't have access to the new group the epic is in.

The following questions become relevant if we go with 2.:

Given an epic is moved from group A to group B.

• How is it displayed to users who only have permission to access group A? (for issues we display them as closed without a system note)
• What happens with labels / parent epics / child epics that exist in group A but not in group B? (for issues we remove labels and milestones without system notes)
• What happens with issues that are part of the epic but invisible to the user who moves the epic? Will they be copied without the user noticing? (for issues the related issues are removed)

@uhlexsis Would you have time to borrow me some of your UX powers?

Hey @winh

Let me know if you want to chat further about this! I think what I got from our call is that we may need to spend more time thinking about the relationships and dependencies between Epics and Issues before tackling moving Epics and issues. Maybe we could be more flexible here when copying and moving, or need to put more thought into error prevention and confirmation. Your idea of starting with "promoting" Epics was interesting and could be a good starting point? It looks like you already pinged @gweaver here which I think will be helpful as we get to the root of the problem we are trying to solve with this.

The epics are typically created in a group for planning broad strokes. The epic will be given sub-epics that flesh out the plan into finer detail.

The idea of planning out work agnostic of group is super interesting and could be something to research. It sounds sort of similar to the templating issue in https://gitlab.com/gitlab-org/gitlab-ee/issues/9398 . I think @annabeldunstone worked on that a bit, so maybe she has some helpful context and feedback here.

What happens with issues that are part of the epic but invisible to the user who moves the epic? Will they be copied without the user noticing? (for issues the related issues are removed)

There is a another aspect to this: Currently it's not possible to add issues from another group to an epic. I guess we want to change that as part of this issue?

@jarka Do you happen to know why we don't support adding issues from another group to an epic?

The initial idea of epics is that they live within a group scope, they are "supposed" to be used for planning within a group.

The initial issue of adding an issue to an epic: https://gitlab.com/gitlab-org/gitlab-ee/issues/3551 but I am not sure where was the initial discussion about the feature.

Thank you! If I understand you correctly, this means that the issue does not make sense as it is.

That's also supported by the current epic-issue-relationship: As soon as we copy over issues to the newly created epic, they will be removed from the old one because each issue can only have one epic.

mentioned in merge request !15128 (closed)

Going forward, I think we have the following options:

1. Make /move only copy author, title, description, and comments of an epic. Labels, issues, parent and child epics would be ignored. In that case I would suggest we rather name the command /clone.
2. Support promoting an epic to the parent group (as suggested in https://gitlab.com/gitlab-org/gitlab-ee/issues/9475#note_149732334).
3. Support physically moving (that is not duplicating) an epic to a child group as long as all issues are within the child group.

@gweaver I'd like to also hear your opinion on this.

1 and 2 make sense to me as a first iteration. 3 seems like it would have a lot of edge cases. Maybe that could be its own issue with some UX consideration?

1. Make /move only copy author, title, description, and comments of an epic.

Apart from comments this is already covered by https://gitlab.com/gitlab-org/gitlab-ee/issues/9398 (which I didn't know existed until now). We can create a follow-up if we think copying over comments needs to be supported as well.

2. Support promoting an epic to the parent group (as suggested in https://gitlab.com/gitlab-org/gitlab-ee/issues/9475#note_149732334).

I have made this a new issue: https://gitlab.com/gitlab-org/gitlab-ee/issues/13634

3. Support physically moving (that is not duplicating)

3 seems like it would have a lot of edge cases.

Yes, I agree. Let's not look into this option for now.

marked this issue as related to #9398

@gweaver I'm closing this in favor of https://gitlab.com/gitlab-org/gitlab-ee/issues/9398 and https://gitlab.com/gitlab-org/gitlab-ee/issues/13634 because there are too many unsolved problems here with not enough clear benefit.

closed

marked this issue as related to #13634

mentioned in epic gitlab-com/marketing/corporate_marketing&1 (closed)