Handle converted CWITs as system defined types in associated tables

MR: Draft: Add HasCustomType concern for custom wor... (!221799 - closed)

Summary

Following the discussion, we need to implement logic to properly handle the relationship between work_item_custom_type_id (for new custom types) and work_item_type_id (for system-defined and converted types).

Problem

With the introduction of custom work item types, we now have two fields that can reference a work item's type:

  • work_item_type_id - Used for system-defined types and converted types
  • work_item_custom_type_id - Used for new custom types

We need to:

  1. Determine the logic for when to set each field
  2. Add validation to ensure only one field can be set at a time (mutual exclusivity)
  3. Prevent work_item_custom_type_id from being set if the custom type was converted from a system type

Requirements

1. Field Setting Logic

Define clear rules for when to populate each field:

  • work_item_type_id: Should be set for:

    • All system-defined work item types (Issue, Epic, Task, etc.)
    • Custom types that have been converted from the old system

  • work_item_custom_type_id: Should be set for:

    • Newly created custom work item types (not converted from system types)
    • Types created through the custom types feature

2. Update getter/setter in TypesFramework::Provider

Ensure that the provider returns the correct WIT based on the new logic for work_item_custom_type_id and work_item_type_id associations

Affected Tables

  • work_item_custom_status_mappings
  • work_item_type_custom_fields
  • work_item_type_custom_lifecycles

Related

Acceptance Criteria

  • Clear logic documented for when to use work_item_type_id vs work_item_custom_type_id
  • Validation ensures mutual exclusivity (only one field can be set)
  • Validation prevents work_item_custom_type_id from being set for converted custom types
  • Tests cover all validation scenarios including:
    • System-defined types use work_item_type_id
    • Converted custom types use work_item_type_id
    • New custom types use work_item_custom_type_id
    • Attempting to set both fields fails validation
    • Attempting to set work_item_custom_type_id for converted type fails validation
  • Existing functionality continues to work with system-defined types
  • New custom types properly use work_item_custom_type_id
Edited by 🤖 GitLab Bot 🤖