Conversation
akabiru
force-pushed
the
feature/73735-expose-project-based-semantic-work-package-identifier-on-the-api
branch
from
56acdca to
4f5db49
Compare
akabiru
changed the title
semanticId in API v3 work package endpoints
This was referenced Apr 10, 2026
akabiru
force-pushed
the
feature/73735-expose-project-based-semantic-work-package-identifier-on-the-api
branch
2 times, most recently
from
2839dc2 to
47c4b8a
Compare
akabiru
changed the base branch from
poc/71645-convert-to-wp-semantic-ids
to
dev
Adds the computed semanticId property to the HAL representer, SQL collection representer, and schema representer. The property is gated behind the semantic_work_package_ids feature flag and returns the value from WorkPackage#identifier. Includes OpenAPI docs and the translation key for the schema name.
Replace the conditional `semanticId` API field with `displayId` which is always present in work package responses. In semantic mode it returns the project-based identifier (e.g. "PROJ-42"), in classic mode it returns the numeric ID as a string. This gives API consumers (frontend, mobile) a single field to read without conditional logic. - Add `WorkPackage#display_id` method that encapsulates the mode check - Update both representers (JSON and SQL) to render `displayId` unconditionally - Update OpenAPI schema documentation
akabiru
force-pushed
the
feature/73735-expose-project-based-semantic-work-package-identifier-on-the-api
branch
from
47c4b8a to
5bbc4e7
Compare
judithroth
approved these changes
Apr 14, 2026
Contributor
judithroth
left a comment
judithroth
left a comment
There was a problem hiding this comment.
LGTM. Nice work!
I have one suggestion on improving the description, but that should not be a big thing.
akabiru
deleted the
feature/73735-expose-project-based-semantic-work-package-identifier-on-the-api
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ticket
https://community.openproject.org/work_packages/73735
What are you trying to accomplish?
Expose a
displayIdfield on API v3 work package endpoints that is always present and returns the appropriate user-facing identifier: the semantic identifier (e.g."PROJ-42") when semantic mode is active, or the numeric ID as a string (e.g."123") in classic mode. This replaces the earlier conditionalsemanticIdfield so that API consumers (frontend, mobile) never need conditional logic — they just readdisplayId.Also adds a
display_idmodel method onWorkPackagethat encapsulates the mode check, and updates both the Ruby and SQL representers to render the new field unconditionally.What approach did you choose and why?
The earlier
semanticIdwas only rendered when semantic mode was active, forcing every consumer to handle both cases. By renaming todisplayIdand making it always-present, downstream code can treat it as the single source of truth for the user-facing identifier. The SQL representer switches betweenidentifierandid::textat the SQL level so there's no Ruby overhead for collection endpoints.Merge checklist