Content
Updated by Wieland Lindenthal 4 days ago
**As** an admin migrating projects/spaces from Jira to OpenProject
**I want to** keep references to the original Jira work item key Key and the internal database Internal Database ID per imported work package
**so that** I can have a clear and robust data mapping from which original Jira work item this work package is the continuation. continuation.
**Explanation**
In Jira work items such as issues and bugs have a public facing key that is "speaking". It is composed of a project/space identifier and a number that increments with every work item in that project/space. That key is not to be confused with the database ID. Keys change in Jira when work items are moved from one space to another. The database ID does not change.
**Acceptance criteria**
* **Origin Key** and **Origin Internal ID** are set automatically during import and cannot be modified afterwards.
* Duplicate **Origin Keys** or **Origin Internal IDs** are not allowed across the instance.
* **Origin Key** (but no **Origin Internal ID)** is visible in the work package table and detail view.
**Nice to have**
* Users can filter and search work packages by **Origin Key** (and not by **Origin Internal ID)** via UI.
* The work package query form includes a filter specifically for both **Origin Key** and **Origin Internal ID**.
* API responses include the **Origin Key** and the **Origin Internal ID** as read-only.
* Attempts to manually set or update the **Origin Key** or the **Origin Internal ID** return an error.
**Permissions and visibility considerations**
* Both fields don't allow any updates via API.
**Translation considerations**
* DE: Ursprungs-ID
**I want to** keep references to the original Jira work item key
**so that** I can have a clear and robust data mapping from which original Jira work item this work package is the continuation.
**Explanation**
In Jira work items such as issues and bugs have a public facing key that is "speaking". It is composed of a project/space identifier and a number that increments with every work item in that project/space. That key is not to be confused with the database ID. Keys change in Jira when work items are moved from one space to another. The database ID does not change.
* **Origin Key** and **Origin Internal ID** are set automatically during import and cannot be modified afterwards.
* Duplicate **Origin Keys** or **Origin Internal IDs** are not allowed across the instance.
* **Origin Key** (but no **Origin Internal ID)** is visible in the work package table and detail view.
**Nice to have**
* The work package query form includes a filter specifically for both **Origin Key** and **Origin Internal ID**.
* API responses include the **Origin Key** and the **Origin Internal ID** as read-only.
* Attempts to manually set or update the **Origin Key** or the **Origin Internal ID** return an error.
**Permissions and visibility considerations**
* Both fields don't allow any updates via API.
**Translation considerations**
* DE: Ursprungs-ID