Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 52,619
    • Issues 52,619
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,541
    • Merge requests 1,541
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #370401
Closed
Open
Issue created Aug 10, 2022 by Melissa Ushakov@mushakov🌻Developer

BE: Work Items - Ability to reorder work items in the Child Items widget

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
  • 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
  • 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.

drag_and_drop_behavior

Tech design

  • Add adjacentWorkItemId and relativePosition (with possible values being BEFORE, AFTER) fields to Types::WorkItems::Widgets::HierarchyUpdateInputType
  • Types::WorkItems::Widgets::HierarchyCreateInputType 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 mutation works and uses EpicTreeNodeInputType structure.
  • Please, keep in mind:
    • Inside LooksAhead#apply_lookahead we use preload . It allows preloading of its args, in the same way, that includes does and accepts associations but not scopes.
    • RelativePositioning concern and respective relative positioning shared examples may be a great option to move forward
    • Complex order configuration for keyset pagination is probably needed.
    • WorkItems::ParentLinks::CreateService inherits from IssuableLinks::CreateService and some methods there may require attention.
    • In Work items positioning within children field in... (#367525 - closed) 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 for manual reordering these children need to support relative positioning.

We have the DB column relative_position needed for this feature but it doesn't include RelativePositioning yet.




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.

Edited Mar 16, 2023 by Petro Koriakin
Assignee
Assign to
Time tracking