Remove types base-type filter from Work Items REST API

Daniyal Arshadrequested to merge
da-drop-types-filter-wi-rest-api into master

What does this MR do and why?

Removes the base-type types filter from the Work Items REST list endpoint (step 2 of 2; step 1, !245442 (merged), formalized work_item_type_ids and has merged). On the Work Items surface types is redundant and misleading now that work_item_type_ids exists, so it is dropped before the API reaches GA.

Changes:

  • Remove the types param from the WI REST list params (positive and negated blocks) and its types -> issue_types rewrite in the filter-params transformer, so passing types no longer filters (it becomes an ignored, undeclared param).
  • Remove the now-moot mutually_exclusive :types, :work_item_type_ids guard from both blocks.
  • Update the parity spec to encode the intentional REST-vs-GraphQL divergence: GraphQL still exposes issueTypes, the WI REST API intentionally does not. types is added to the known exceptions on both the positive and negated GraphQL filter sets.
  • Replace the types filter spec with a regression test asserting types no longer filters, and drop the types rows from the mutual-exclusivity table. The work_item_type_ids coverage from step 1 is kept.

The finder (Issues::IssueTypesFilter / with_issue_type), the legacy issues REST API, and GraphQL base-type filtering (issueTypes) are untouched. The frontend list view only sends work_item_type_ids, so it is unaffected.

Related

Breaking change / risk note

The WI REST list endpoint is hidden and in the experiment lifecycle, which reserves the right to change the surface before GA, so dropping types is permitted. Note the list endpoint is no longer behind the work_item_rest_api feature flag (that flag now gates only the single-item and write endpoints), so the protection here is the experiment lifecycle plus hidden status, not the flag. No internal consumers send types; external clients on the experimental API should move to work_item_type_ids.

Merge request reports