Expose custom work item types in GraphQL APIs

Daniyal Arshadrequested to merge
da-expose-new-custom-type-in-fe-apis into master

Issue: [BE] [API] Expose new custom types in all APIs ... (#581939 - closed)

What does this MR do and why?

Part of the Configurable Work Item Types feature. When work_item_configurable_types is enabled for a namespace, custom work item types need to be surfaced across all GraphQL APIs that the frontend relies on to render work items.

APIs where custom types are now exposed (this MR)

These two resolver methods were returning raw system-defined types, bypassing the Provider which maps system types to their custom equivalents for the namespace:

API Field Change
WorkItemType supportedConversionTypes Now resolves through Provider — returns custom type names where applicable
WorkItemWidgetDefinitionHierarchy allowedChildTypes / allowedParentTypes Now resolves through Provider — returns custom type names where applicable

APIs where custom types were already available (no changes needed)

API Field How
Group / Project / Namespace workItemTypes Already uses TypesFinder → Provider
WorkItem workItemType Already uses HasType concern → Provider
WorkItemType canUserCreateItems Delegates to base type — works correctly for custom types

References

Screenshots or screen recordings

Scenario Screenshot
Scenario 1 - Available work item types: workItemTypes on a group with the flag enabled returns custom types alongside system types. Converted types replace their system counterpart (e.g. "Converted Issue" replaces "Issue"). scenario1_available_work_item_types
Scenario 2 - Work item type of an item: A work item created with a custom type correctly returns the custom type name and ID in workItemType. scenario2_work_item_type_of_item
Scenario 3 - Supported conversion types: supportedConversionTypes reflects the Provider's type list. Converted types appear with their custom name. scenario3_supported_conversion_types
Scenario 4 - Hierarchy: "Converted Issue" (converted from system Issue) has allowedChildTypes returning "Subtask" (converted from system Task) instead of "Task". The system ID WorkItems::Type/5 is preserved by design. scenario4b_converted_issue_child_subtask
Scenario 5 - canUserCreateItems: Custom types correctly inherit canUserCreateItems from their base system-defined type. scenario5_can_user_create_items
Scenario 6 - Feature flag disabled: Only system-defined types returned. "Issue" reappears, no custom types visible. scenario6_feature_flag_disabled

How to set up and validate locally

  1. Enable the feature flag for a group in rails console: 
    group = Group.find_by_full_path('your-group')
Feature.enable(:work_item_configurable_types, group)
  2. Ensure a custom work item type exists (or create one): 
    WorkItems::TypesFramework::Custom::Type.create!(
  name: 'Bug', namespace: group, base_type: :issue
)
  3. Open the GraphQL Explorer and run the queries for each scenario below.

Scenario 1 — Available work item types 

{ group(fullPath: "your-group") { workItemTypes { nodes { id name } } } }

Expected: Custom types included. Converted types replace their system counterpart.

Scenario 2 — Work item type of an item 

{ workItem(id: "gid://gitlab/WorkItem/<id>") { workItemType { id name } } }

Expected: Returns the custom type name for work items created with a custom type.

Scenario 3 — Supported conversion types 

{
  group(fullPath: "your-group") {
    workItemTypes {
      nodes { name supportedConversionTypes { id name } }
    }
  }
}

Expected: Conversion types reflect the Provider's list — converted types appear with their custom name.

Scenario 4 — Hierarchy 

{
  group(fullPath: "your-group") {
    workItemTypes {
      nodes {
        name
        widgetDefinitions {
          type
          ... on WorkItemWidgetDefinitionHierarchy {
            allowedChildTypes { nodes { id name } }
            allowedParentTypes { nodes { id name } }
          }
        }
      }
    }
  }
}

Expected: Child/parent types reflect the Provider's list. If Task is converted to "Subtask", "Converted Issue" allowedChildTypes returns "Subtask" instead of "Task".

Scenario 5 — canUserCreateItems 

{ group(fullPath: "your-group") { workItemTypes { nodes { name canUserCreateItems } } } }

Expected: Custom types inherit canUserCreateItems correctly from their base type.

Scenario 6 — Feature flag disabled 

Feature.disable(:work_item_configurable_types)

Re-run Scenario 1. Expected: Only system-defined types returned, no custom types visible.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Daniyal Arshad

Merge request reports