Skip to content

Draft: parent child widget

Jan Provaznik requested to merge jp-spike-pc into master

What does this MR do and why?

An experiment which:

  • adds basic support for widgets to WorkItems GraphQL API (to the work item query, and create mutation)
  • adds parent/child widget plus description/related links widgets - these are not production ready, but should serve the purpose of getting idea how widgets might be used
  • allows to set parent work item using generic WorkItem create mutation - the reason is that parent will be set when creating a work item (so it will be part of creation process). Because having all widgets to use one big mutation might be problematic, some widgets should use a separate mutation in future.
mutation {
  workItemCreate(input: {
    descriptionWidget: {text: "asdf"},
    parentLinkWidget:{parentId: "gid://gitlab/WorkItem/1"},
    projectPath: "flightjs/flight", title: "asdf",
    workItemTypeId: "gid://gitlab/WorkItems::Type/1"}) {
    
    workItem {
      id
      description
      widgets {
        type
        ... on WorkItemWidgetParentLink {
          parent {
            id
          }
        }
      }
    }
    errors
  }
}
  • exposes work items widgets (description, related links):
query {
  workItem(id: "gid://gitlab/WorkItem/1") {
    id
    workItemType {
      id
    }
    title
    widgets {
      type
      ... on WorkItemWidgetDescription {
        text
      }
      ... on WorkItemWidgetLinks {
        relatedWorkItems {
          nodes {
          	id
          	issueLinkType
          }
        }
      }
      ... on WorkItemWidgetParentLink {
        parent {
          id
        }
        children {
          nodes {
            id
          }
        }
      }
    }
  }
}

This code is just an experiment, which may serve for inspiration how final/production-ready implementation might roughly look like, but nothing here is written in stone and can be changed.

Related to #358195 (comment 920166195)

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Jan Provaznik

Merge request reports