Use displayId in work package URLs for semantic identifier routing#22733
Draft
Conversation
akabiru
changed the title
Routes already accept semantic identifiers (e.g. PROJ-7) via WP_ID_URL_PATTERN, but all frontend-generated links still used numeric PKs. This wires displayId into every navigation path so the browser URL bar shows the semantic form when available. Key design decision: data-work-package-id attributes on <a> elements stay numeric — the selection/hover system is keyed by PK. Only the href gets the semantic ID via a new optional routingId parameter on UiStateLinkBuilder. Changes span table links (ID column, linked WP fields, details action), navigation handlers (list view, embedded tables, boards, BCF, calendar), breadcrumbs, tabs, hierarchy, single view, context menu, quickinfo macro, and post-creation redirect. API-only paths (time entries, share, hover cards, progress modal) are deliberately left with numeric IDs — they never appear in the address bar.
akabiru
force-pushed
the
implementation/73797-use-displayid-in-work-package-urls
branch
from
6574c91 to
530eecc
Compare
Stateful navigation changes ($state.go callers) moved to a follow-up PR with P1 bug fixes for focus/selection, card highlight, bulk delete, and cache coherence. Retained changes only modify href attributes and URL strings — click handlers still read data-work-package-id (numeric PK), so no semantic IDs leak into Angular state params.
2 tasks
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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/wp/73797
Builds on #18997
What are you trying to accomplish?
When a project has semantic work package identifiers enabled, clicking any work package link still showed the numeric PK in the browser URL bar (e.g.
/work_packages/42/activity). This changes all frontend-generated URLs to use the semanticdisplayIdinstead (e.g./work_packages/PROJ-7/activity), giving users readable, shareable URLs that match the identifiers they see in the UI.The backend already accepts both forms — this is purely a frontend wiring change.
What approach did you choose and why?
The tricky part is that the same
<a>element serves two masters: thehreffor navigation, anddata-work-package-idfor the selection/hover system. Selection is keyed by numeric PK everywhere — row CSS classes (wp-row-42),setSelection(), hover sync withparseInt()— so changing the data attribute would break a lot of things.The fix separates these two concerns:
UiStateLinkBuilder now takes an optional
routingIdthat only affects thehref. The data attribute stays numeric. This covers all table/card link elements where one DOM node does both routing and selection.Navigation handlers (list view, embedded tables, boards, BCF, calendar) use a
resolveRoutingId()helper that looks up the WP from the States cache and returnsdisplayId ?? workPackageId. This covers click-to-navigate flows where the event carries a numeric ID from the data attribute but the URL should be semantic.Direct callers (breadcrumbs, tabs, hierarchy, single view, context menu, quickinfo macro, post-creation redirect) just inline the
displayId ?? idpattern since they already have the WP resource in scope.API-only paths (time entries, share dialogs, hover cards, progress modal) are deliberately left with numeric IDs — they never appear in the address bar so there is no user benefit to changing them, and it avoids unnecessary risk.
Everything falls back to numeric IDs gracefully when
displayIdis not set (classic mode).Merge checklist