## Problem to solve The order in which records appear in the child widget is important because it can represents the sequence in which they should be worked on. ## Proposal Allow users to re-order (drag and drop) child records in the child items widget. Noting that users should be able to reparent child items through drag and drop similar to the epic child feature. ## Acceptance Criteria #### Tasks within work items - [ ] Move an existing task to the top of the list - [ ] Move an existing task to the bottom of the list - [ ] Move an existing task to the middle of the list - [ ] Move an existing task to another work item and set a manual position - [x] Every newly created task is added to the bottom of the hierarchy #### Hierarchy Widget for any work item type - [ ] Move an existing child to the top of the Hierarchy - [ ] Move an existing child to the bottom of the Hierarchy - [ ] Move an existing child to the middle of the Hierarchy - [ ] Move an existing child to another Hierarchy and set a manual position - [x] Every newly created work item is added to the bottom of the hierarchy #### Please prepare Work Item Hierarchy Widget backend to mimic the current experience found in Epics when dragging and dropping records.  ## Tech design - Add `adjacentWorkItemId` and `relativePosition` (with possible values being `BEFORE`, `AFTER`) fields to [Types::WorkItems::Widgets::HierarchyUpdateInputType](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/graphql/types/work_items/widgets/hierarchy_update_input_type.rb) - [Types::WorkItems::Widgets::HierarchyCreateInputType](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/graphql/types/work_items/widgets/hierarchy_create_input_type.rb) should handle default behavior: newly created work item is added to the bottom of the hierarchy. - handle error cases: - `Relative position is not valid.` - `Relative position cannot be combined with childrenIds.` - `The adjacent work item\'s parent must match the new parent work item.` - `The adjacent work item\'s parent must match the current parent work item.` - It can be helpful for inspiration to look at the way that [`Reorder`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/graphql/mutations/epic_tree/reorder.rb) mutation works and uses [`EpicTreeNodeInputType`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/graphql/types/epic_tree/epic_tree_node_input_type.rb) structure. - Please, keep in mind: - Inside [`LooksAhead#apply_lookahead`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/graphql/resolvers/concerns/looks_ahead.rb#L17-23) we use [preload](https://api.rubyonrails.org/classes/ActiveRecord/QueryMethods.html#method-i-preload) . It allows preloading of its args, in the same way, that [includes](https://api.rubyonrails.org/classes/ActiveRecord/QueryMethods.html#method-i-includes) does and accepts associations but not scopes. - [RelativePositioning](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/concerns/relative_positioning.rb) concern and respective [relative positioning shared examples](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/support/shared_examples/models/relative_positioning_shared_examples.rb) may be a great option to move forward - [Complex order configuration for keyset pagination](https://docs.gitlab.com/ee/development/database/keyset_pagination.html#complex-order-configuration) is probably needed. - [WorkItems::ParentLinks::CreateService](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/work_items/parent_links/create_service.rb) inherits from [IssuableLinks::CreateService](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/issuable_links/create_service.rb) and some methods there may require attention. - In https://gitlab.com/gitlab-org/gitlab/-/issues/367525+ ordering by `created_at` had been introduced. Until manual reordering in used by frontend code, we should use `work_items` `created_at` value to set `relative_position` values for all existing `work_item_parent_links` records. ## Information to note Per [this comment](https://gitlab.com/gitlab-org/gitlab/-/issues/367525#note_1223730457) for manual reordering these children need to [support relative positioning](https://gitlab.com/gitlab-org/gitlab/-/issues/358195#note_932035936). We have the DB column `relative_position` needed for this feature but it doesn't include `RelativePositioning` yet. <br><br><br> <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->