With #13633 (closed), we're adding support for reordering Epics and Issues as a combined list. The next logical step in the Epics Tree UX is to allow user to move any item (Issue or an Epic) inside of an Epic, and thus changing parent Epic of that item. This was also discussed to be included in the tree originally but we're breaking down entire effort into smaller issues, so this issue is tracking just the part of nested drag and drop. When dragging an item to a closed child epic, the child epic should expand so they can drop the item within.
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.
I don't think we do as original proposal of highlighting target epic in shade of blue would suffice, unless @annabeldunstone has something to add there.
@donaldcook@kushalpandya I agree, I think we can continue with the original design, but I think we may need to revisit the line separator that @kushalpandya implemented during one of the iterations. Having items shift around constantly can be incredibly annoying, especially when we add this next interaction of nesting items.
I agree! If they try to drag into an area that is out of view, I assume it will auto scroll to that area? I'm happy with the original design as well. @donaldcook
Thanks for the ping @donaldcook , I am at capacity trying to figure some roadmap stuff out atm, summoning the wisdom of @hollyreynolds for a quick review.
@donaldcook Yes, let's move forward with the original drag/drop design, just within the nested context. One question, does the current functionality open/expand a nested item when they drag over it automatically? Or would it have to be opened already for them to drag into it?
@kokeefe Don't think so. We will go with the original design but I do want to be sure it will open the child epic folder on drag if they attempt to move an item into one that is closed. Should I update the description with such or do we need to wait on confirmation from Donald that this is possible?
Hello @kushalpandya and/or @cablett. I noticed you did the work on epic tree and I could use some pointers.
To move a child from an epic to another, I'd like to use a GraphQL mutation. Currently, we use axios.post to add an item to an epic so I can't use that and I can't find issuable_references (which is what I think I'd need to mutate) in the GraphQL reference documentation. Does it need to be added somewhere in the API
Also I want to make sure I'm going down the right way before I'm too far gone so if there's a better way or if you have any implementation recommendations, I'll take them. Thank you!
After doing some investigation, with a great amount of help from @cablett, we've realised this requires some backend work. We currently don't have any service that would allow use to change a parent of a child epic or issue, considering the fact that we also need to inform its position among the epic's children.
I have a WIP MR with basic frontend (currently can move a child to an epic if it already has children, still heaps to be done there), a GraphQL mutation with a vague backend connection that Charlie helped me put together: !28629 (merged)
With the proper service being called in changeParent.rb, this should work.
This will need some backend work, since (IIRC) we do EpicIssue link updates with the REST API, not with GraphQL (see ee/lib/api/epic_issues.rb).
I think a good start to the backend might look like:
We may be able to use the existing GraphQL mutation EpicTree::Reorder and add an optional new_parent_id to the Types::EpicTree::EpicTreeNodeInputType. If the new_parent_id param is missing, the TreeReorderService can be used as normal.
I think we'll probably need a different service that will update the Epic or EpicIssue (checking for auth, etc) and then determine the order according to the provided inputs (maybe calling TreeReorderService )
@donaldcook We need to move this forward.
Organizing work in a parent epic is a primary function in the Epic Tree and not being able to move items between sub-epics is frustrating and requires multiple tabs, copy/paste, and ton of clicks.
@johnhope do any backend engineers have bandwidth to take this on? Should we move the workflow label back to workflowready for development so they know it still needs to be picked up?