# Feature COMMS-1083 - API v3: allow filtering work packages by their semantic identifier (e.g. PROJ-42) in the id filter

Project: Stream Communicator
Status: merged
URL: https://community.openproject.org/work_packages/COMMS-1083

## Planning

| Attribute | Value |
| --- | --- |
| Date |  |
| Priority | Medium |
| Target versions | 18.0.0 |
| Sprint | Sprint 20 |
| Backlog bucket |  |
| Votes |  |
| List |  |
| Roadmap |  |
| Relevance |  |

## OPEN POINTS / FEEDBACK

_No work packages_

## Features and Chunks

_No work packages_

## Bugs and other work packages

_No work packages_

## Technical Details

| Attribute | Value |
| --- | --- |
| Module |  |
| Feature Flag |  |
| Requires doc change | No |
| Enterprise plan | Community (COM) |

## Details

| Attribute | Value |
| --- | --- |
| Pull preview |  |
| Mockups |  |
| Accessibility | No |

## People

| Attribute | Value |
| --- | --- |
| Assignee |  |
| Accountable |  |
| Product manager |  |
| Developers | Tom Hykel |
| Designer |  |
| Ordered by |  |
| Signed off by |  |
| Interest by |  |

## Estimates and progress

| Attribute | Value |
| --- | --- |
| PD (min) |  |
| PD (max) |  |
| Work |  |
| Labor costs |  |

## Description

**As** a developer of an integration that consumes the API v3 (e.g. the XWiki OpenProject integration)
**I want to** filter work packages by their project-based semantic identifier (e.g. `PROJ-42`) in API v3 queries
**so that** users can reference work packages by the key they see in OpenProject, without the integration having to resolve each key to a numeric ID first.

**Current behaviour**

  - `GET /api/v3/work_packages/PROJ-42` works, and work packages expose a `displayId` property.
  - But the `id` filter only accepts numeric IDs: `filters=[{"id":{"operator":"=","values":["PROJ-42"]}}]` is rejected because `FilterForWpMixin#allowed_values_subset` does `visible_scope.where(id: values)`.
  - <mention class="mention" data-id="73761" data-type="work_package" data-text="#73761">#73761</mention> made the "ID" filter find semantic identifiers in the UI, but only through the autocompleter (which uses the `typeahead` filter); the saved query still contains numeric IDs. <mention class="mention" data-id="73826" data-type="work_package" data-text="#73826">#73826</mention> (which asked for this) was closed as a duplicate of <mention class="mention" data-id="73761" data-type="work_package" data-text="#73761">#73761</mention>.
  - The `typeahead` filter does match semantic identifiers, but as a prefix match OR'ed with subject / project name / type / status matches (`PROJ-4` also returns `PROJ-42`, `PROJ-400`, and any work package whose subject contains `PROJ-4`), so it can't be used as an exact filter.

**Acceptance criteria**

  - The `id` filter of the work packages API v3 (and of the work package queries) accepts semantic identifiers as values, alone or mixed with numeric IDs, e.g. `{"id":{"operator":"=","values":["PROJ-42","PROJ-43","1234"]}}`, with `=` and `!` operators.
  - Former identifiers (aliases kept after a project rename, `work_package_semantic_aliases`) also match.
  - Matching is exact (no prefix / fuzzy match).
  - Alternatively, a dedicated exact-match filter (e.g. `displayId` / `identifier`) would work just as well.

**Permissions and visibility considerations**

  - Visibility of work packages stays the same. Users only find work packages they are allowed to see.

**Out of scope**

  - Changes to the global search or the autocompleters (already covered by <mention class="mention" data-id="73761" data-type="work_package" data-text="#73761">#73761</mention> / <mention class="mention" data-id="74302" data-type="work_package" data-text="#74302">#74302</mention>).