Draft an API structure for needed configuration

Proposal

Introduce a configuration based approach for removing the hardcoded checks in the codebase

The proposal is to introduce the widget level config under widgetdefinitions and broader configurations which are not associated with any type to the configuration key

Use cases

Configuration name Part of which API Response example / Type Any alternative to the current implementation Related work item(s)

@stefanosxan @engwan @msaleiko @cngo comments

propagatesParentMilestone

namespaceWorkItemTypes

WorkItemTypeConfiguration

#580374

isGroupWorkItem

workItemByIid

{
    "data": {
        "workspace": {
            "id": "gid://gitlab/Group/9970",
            "workItem": {
                "id": "gid://gitlab/WorkItem/176869994",
                "iid": "19879",
                "isGroupWorkItem": true,
                "namespace": {
                    "id": "gid://gitlab/Group/9970",
                    "fullPath": "gitlab-org",
                    "name": "GitLab.org",
                    "fullName": "GitLab.org",
                    "webUrl": "https://gitlab.com/groups/gitlab-org",
                    "__typename": "Namespace"
                },
                "__typename": "WorkItem"
            },
            "__typename": "Namespace"
        }
    }
}
  1. If the backend can identify on its own and return work items depending on full path , we can get rid of this
  2. Or we can use the namespace id and name to identify if its a group work item / project work item

Screenshot 2025-12-04 at 10.55.40 AM.png

#580374

#580371

What about if the namespace returns a type? Then you should be able to know which query to make?

supportsRoadmapView

namespaceWorkItemTypes

WorkItemTypeConfiguration

#580373

showProgressPopover

namespaceWorkItemTypes

widgetDefinitions

#580369

autoExpandTreeOnDrag

namespaceWorkItemTypes

widgetDefinitions

#580366

useLegacyView/isLegacyWorkItemType

namespaceWorkItemTypes

WorkItemTypeConfiguration

#580363

#580359

canPromoteToObjective

namespaceWorkItemTypes

WorkItemTypeConfiguration

  1. We have a separate dropdown item to Promote to objective

#580362

showProjectSelector

`namespaceWorkItemTypes

WorkItemTypeConfiguration

The condition for this to be passed in create work item modal is !isEpic , there may be another way , like the above isGroupWorkItem

#580362

supportsMoveAction

namespaceWorkItemTypes

WorkItemTypeConfiguration

Only issues can be moved as of now

#580362

rollUp

namespaceWorkItemTypes

widgetDefinitions

Dates are rolled up only for epics

#580359

type WorkItemType {
  id: ID!
  name: String!
  iconName: String!
  configuration: WorkItemTypeConfiguration!
}
type WorkItemTypeConfiguration {
  supportsRoadmapView: Boolean!
  supportsMoveAction: Boolean!
  supportsTypeConversion: Boolean!
  showProjectSelector: Boolean!
  propagatesParentMilestone: Boolean!
  useLegacyView: Boolean! // we can also use `isLegacyWorkItemType`
}
#import "./work_item_status.fragment.graphql"

fragment WorkItemTypeFragment on WorkItemType {
  id
  name
  iconName
  supportedConversionTypes {
    id
    name
  }
  widgetDefinitions {
    type
    ... on WorkItemWidgetDefinitionStartAndDueDate {
      rollUp
    }
    ... on WorkItemWidgetDefinitionProgress {
      showProgressPopover
    }
    ... on WorkItemWidgetDefinitionHierarchy {
      autoExpandTreeOnDrag
    }
  }
}
Edited by Deepika Guliani