Child task of https://gitlab.com/gitlab-org/gitlab/-/work_items/605888 (step 1 of 2). ## Goal Formalize the `work_item_type_ids` filter on the Work Items REST list endpoint. Today it works only via an undeclared param (the endpoint reads the raw `params` hash, so the key rides through to the finder), and the frontend already depends on it in production. This task declares it properly: typed, coerced, validated, with a mutual-exclusivity guard against the base-type `types` filter. It is a no-op for the frontend, which already sends `work_item_type_ids[]=<int>`. This does NOT remove the `types` filter. That is the separate step-2 task. ## Background (why this is safe and why it is needed) - `work_item_type_ids` currently flows through because `API::Helpers::WorkItemsFilterParams#transform` builds finder params from the raw params hash, not from `declared(params)`. The key matches what the finder expects, so it reaches `WorkItems::WorkItemsFinder` -> `Issues::IssueTypesFilter#by_work_item_type_ids` -> the `with_work_item_type_ids` scope on the model. Verified end to end (see parent issue). - It takes INTEGER ids. GID input returns zero results (the finder does `where(work_item_type_id: [...])`). The frontend sends integers. - Combined with the base-type `types` filter it silently ANDs to an empty set (e.g. `?types=issue&work_item_type_ids[]=2` returns 0, no error). That is the footgun this task guards with `mutually_exclusive` (until `types` is removed in step 2). So the finder and model plumbing already exist (from the GraphQL implementation). This task is purely the API param declaration + validation. No finder, model, entity, or migration change. ## Implementation checklist - [ ] In `lib/api/helpers/work_items/list_params.rb`, declare the param in the top-level filter block (mirror the existing `types` declaration around lines 19-22): optional :work_item_type_ids, type: Array[Integer], desc: 'Filter by work item type IDs.', coerce_with: ::API::Validations::Types::CommaSeparatedToIntegerArray.coerce - [ ] Declare it again in the `not` block (mirror the `not` `types` declaration around lines 136-139) with a suitable `desc` (e.g. 'Exclude work items with these work item type IDs.'). The negated finder path already exists (`IssuesFinder#by_negated_work_item_type_ids`). - [ ] Add `mutually_exclusive :types, :work_item_type_ids` in the top-level block and in the `not` block (this file already uses `mutually_exclusive`, e.g. for `assignee_usernames` / `assignee_wildcard_id`). This prevents the silent-AND footgun while `types` still exists. It becomes moot once step 2 removes `types`. - [ ] Confirm the endpoint still passes the param through unchanged. Because `work_item_type_ids` already matches the finder key, declaring it should be transparent - verify no transformer rewrite is needed in `lib/api/helpers/work_items_filter_params.rb` (it is not, but confirm). - [ ] Parity spec: `work_item_type_ids` is currently listed in `known_exceptions` in `spec/support/shared_examples/lib/api/work_items/parity_shared_examples.rb`. Now that it is a declared param, revisit whether it should come out of the exceptions list. (The `types`-vs-GraphQL parity premise changes fully in step 2; for step 1, just make the parity spec pass with the newly declared param - do not pre-empt the step-2 direction here.) ## Acceptance criteria - [ ] `GET /projects/:id/-/work_items?work_item_type_ids[]=2` returns only type-2 work items (unchanged behavior, now via a declared param). - [ ] Array OR still works: `?work_item_type_ids[]=2&work_item_type_ids[]=9` returns types 2 and 9. - [ ] `?not[work_item_type_ids][]=1` excludes type-1 items. - [ ] Non-integer input is rejected/coerced per the integer-array coercion (not silently passed as strings). - [ ] `?types=issue&work_item_type_ids[]=2` now returns a clear mutually-exclusive validation error instead of silently ANDing to zero. - [ ] The frontend list view is unaffected (it already sends integer `work_item_type_ids[]`). - [ ] Works on both project and group list endpoints (both compose from `work_items_filter_params`). ## Testing - [ ] Add a `work_item_type_ids` context to the filter shared example `spec/support/shared_examples/api/work_items_filter_shared_examples.rb` (where the `types` context lives). It is exercised by the project and group list request specs in `spec/requests/api/work_items_spec.rb` via `it_behaves_like 'work item listing filters'`, so this covers both surfaces. Cover: positive filter, array OR, the `not` block, and the mutual-exclusivity error with `types`. - [ ] Ensure the parity spec passes. ## Size Very small. Roughly 15-25 lines of production code (param declarations + mutual exclusivity) and 40-60 lines of tests. No finder, model, entity, transformer, or migration change. Add a changelog trailer.