This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Pinged the wrong Alexis @kokeefe ! Although dang, I wish I had the Alexis handle.
Take a look at the quick designs I attached in #10482 .. .are those the main places epic information would be displayed for issues? If so we are gtg (I can just add any specs if needed), if not I can add more!
I have a customer interested in this one. Right now, they are having trouble utilizing Roadmaps because they've already created a bunch of issues and Milestones for their sprint planning. It would be fantastic if they could quickly and easily associate existing issues to their newly created Epics!
cc @cnicholson
Why interested: copy/pasting URLs takes a long time when there are many issues
Current solution for this problem: tears (and they can manually enter the URL in the Epic
How important to them: Very, being able to utilize roadmaps and reorganize their existing instance with ease will greatly assist their team with GitLab adoption
@gweaver@kokeefe@dknopf1 Editing multiple issues at a time seems to be more difficult, I thought I had the ability to select more that one issue and update "some" of the detail fields like, milestone, weights, assignee, etc. I requested Epic, which i think is reflected in this story, but really every field available should be editable from this view. As of today, I am only seeing milestone and label.
@egrieff Given that this touches what is usually groupproject management functionality would you be able to dig into the code a bit and help us understand the complexity of the backend work here?
Sure! I was involved in the backend work for implementing bulk edit at the group level (labels #7250 (closed) & milestones #7249 (closed)) so that could be helpful
@johnhope From a backend perspective, we have a service that deals with bulk updates at the project and the group level, and it would already be able to update multiple issues epic if the param was present.
For this to work, frontend changes should add the missing field to the sidebar (for project and group level) considering it should only be available for issues, as it's a shared template across MRs and Epics.
Also, because of the way we handle updating an issue's epic, I believe the param epic should be used, rather than epic_id. Maybe this complicates a little the logic for the epics dropdown, but other than deciding on the specific param and allowing it to be passed to the service, the backend work should be minimal here.
Is it a shared service for both project and group level, or does it make sense to split this work up that way? For the frontend, it is not shared, so it can definitely be split up.
@donaldcook I think I would give this a weight of 2 for backend but I assume the frontend work will be more complex so I won't assign any weight yet. Maybe you could ping someone to estimate a frontend weight?
Also, I can start working on this and have the changes ready for frontend as I think they can be worked on independently.
I think 2 should be fine for frontend. Though it has search and other static properties which could take some additional time as well which I can't assess right now.