Skip to content

Allow filtering by legacy requirement IID in Work Items API

What does this MR do and why?

Allow filtering by legacy requirement IID for work items of Requirement type via Work Items API.

How to set up and validate locally

  1. Create some requirements
  2. Use the following GraphQL query to identify by legacy iid:
query {
  project(fullPath: "flightjs/Flight") {
    workItems(requirementLegacyWidget: { legacyIids: ["2"] }) {
      nodes {
        id
        title
        widgets {
          type
          ... on WorkItemWidgetRequirementLegacy {
            legacyIid
          }
        }
      }
    }
  }
}

It should look something like:

{
  "data": {
    "project": {
      "workItems": {
        "nodes": [
          {
            "id": "gid://gitlab/WorkItem/648",
            "title": "make it sparkle",
            "widgets": [
              {
                "type": "STATUS"
              },
              {
                "type": "REQUIREMENT_LEGACY",
                "legacyIid": 2
              },
              {
                "type": "DESCRIPTION"
              },
              {
                "type": "NOTES"
              }
            ]
          }
        ]
      }
    }
  }
}

DB review

Query plan

https://console.postgres.ai/shared/cc755e69-c7ac-48a9-8dfc-6085d3e33d38
SELECT 
  "issues".* 
FROM 
  "issues" 
  INNER JOIN "work_item_types" "work_item_type" ON "work_item_type"."id" = "issues"."work_item_type_id" 
  INNER JOIN "requirements" "requirement" ON "requirement"."issue_id" = "issues"."id" 
WHERE 
  "issues"."project_id" = 278964 
  AND "work_item_type"."base_type" = 3 
  AND "requirement"."iid" IN (1, 2, 3) 
  AND (
    requirement.project_id = issues.project_id
  )

MR acceptance checklist

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

Related to #383017 (closed)

Edited by Mario Celi

Merge request reports

Loading