Content
View differences
Updated by Wieland Lindenthal about 1 month ago
**As** a user of the API
**I want to** see the project-based semantic work package identifier and the user-facing identifier in the API
**so that** I can use the values if I like
**Acceptance criteria**
* the endpoints for getting work packages in the API v3 expose the `display_id` (based on the `Setting::WorkPackageIdentifier` either database ID or semantic ID), see <mention class="mention" data-id="73715" data-type="work_package" data-text="#73715">#73715</mention> for implementation details)
**Technical notes**
* We should not expose the `identifier` or `sequence_number` on the API
* In case the WorkPackageIdentifier Setting was set to `semantic` and then back to `classic`, and a work package is then moved from project A to project B, it's identifier will not be updated any more and still reference project A. Same for the sequence number.
* `display_id` should be a method of `WorkPackage` (and be called in the representer) since we also need it in views.
**Permissions and visibility considerations**
* Visibility of work packages does not change
**Translation considerations**
* No translations needed for the API
**Release communication** **Out of scope**
* Dear community developers, in 17.5 we will allow OpenProject to have work package identifiers that carry meaning by consisting a short project identifier and a per project sequence-number, eg \`#ABC-123\`. Many people that have worked with Jira are familiar with that pattern.
* If you are building or maintaining an app that consumes the OpenProject API V3 please start using the work package field `displayID` instead of `id` for displaying the identifier. Then your application will not need to know what mode the OpenProject instance is configured. `displayID` will always show the right one.
* The `id` field will continue to have the database ID. And for API requests you should keep using that one, e.g. for filtering etc.
<br>
**I want to** see the project-based semantic work package identifier and the user-facing identifier in the API
**so that** I can use the values if I like
**Acceptance criteria**
* the endpoints for getting work packages in the API v3 expose the `display_id` (based on the `Setting::WorkPackageIdentifier` either database ID or semantic ID), see <mention class="mention" data-id="73715" data-type="work_package" data-text="#73715">#73715</mention> for implementation details)
**Technical notes**
* We should not expose the `identifier` or `sequence_number` on the API
* In case the WorkPackageIdentifier Setting was set to `semantic` and then back to `classic`, and a work package is then moved from project A to project B, it's identifier will not be updated any more and still reference project A. Same for the sequence number.
* `display_id` should be a method of `WorkPackage` (and be called in the representer) since we also need it in views.
**Permissions and visibility considerations**
* Visibility of work packages does not change
**Translation considerations**
* No translations needed for the API
**Release communication**
* Dear community developers, in 17.5 we will allow OpenProject to have work package identifiers that carry meaning by consisting a short project identifier and a per project sequence-number, eg \`#ABC-123\`. Many people that have worked with Jira are familiar with that pattern.
* If you are building or maintaining an app that consumes the OpenProject API V3 please start using the work package field `displayID` instead of `id` for displaying the identifier. Then your application will not need to know what mode the OpenProject instance is configured. `displayID` will always show the right one.
* The `id` field will continue to have the database ID. And for API requests you should keep using that one, e.g. for filtering etc.
<br>